Installing 1.1.1
Sun, 02/21/2010 - 00:41
I'm in the middle of developing a large application (using 1.1) and would like to know the ramifications of installing 1.1.1 into that environment. It appears there are changes that would benefit.
1. Is it necessary to reinstall all plug-ins?
2. I've made changes to many configuration files, like configuration.inc.php, header.inc.php, footer.inc.php. Also, I've made some changes to the styles.css. Can I just use the files I've changed or do I need to apply the same changes to the files included in 1.1.1?
3. Are the plug-ins for 1.1 the same for 1.1.1? Were they modified for 1.1.1?
Thanks.
Here's how you should be able to upgrade:
- Replace the /includes/_core folder with the new one
- Replace the /assets/_core folder with the new one
- Review configuration.inc.php and check to make sure there weren't any new constants added to it (I honestly don't remember :-/)
That's it, really.
1. Reinstalling plugins: should not be needed.
2. Configuration files: keep 'em, with the exception of reviewing configuration.inc.php like I mentioned above. Don't need to change styles.css at all.
3. Plugins are completely separate from the core. We have not broken backward compatibility - all the plugins that worked with QCubed 1.1 will work with 1.1.1.
Hope this helps. Good luck!
Thanks Alex for your quick response. It is very much appreciated! Sounds pretty easy.
Alex, the __AP_JS_ASSETS__ constant is missing from the configuration.inc.php. Easy enough to correct, but I wonder if anything will be affected if I need to rerun codegen.
Thanks.
I actually never heard about that constant. Where is it used? Are you sure it's a part of the core, and not something you added?
To have confidence during upgrades like this, you absolutely must have a version control system. You'll then easily see what changes codegen makes / what else is different between releases, in detail.
Alex, that appears to be the only difference, and no it's not something I added. I don't really know where it came from. It must have been added by one of the plugins, but which one, I don't know. The plugins I have installed are:
Autocomplete, FCKEditor, QVisualCalendar, and Firebug.
I haven't implemented an SVN yet, because I'm a one man show and it's all pure new development. I haven't reached the point where I'm changing anything or have something to be changed. However, that being said, it appears I'll need to get QCubed under Tortoise control.
Thanks Alex, it's appreciated!
Ummm. Plugins are not allowed to modify the configuration.inc.php file - they simply don't have access to it during the installation process. What happens when you simply delete that constant? Is there something that breaks? If so, can you post a call stack?
LaCeja, you absolutely must begin using source control ASAP. It doesn't matter that you're a one-man show. Most of us here are as well (we run our own little consulting companies). There are hundreds of articles written about source control, but I will summarize in a few key points:
- Backup in case of catastrophic hardware failure
- Being ALWAYS able to revert to a version that works
- Ability to have "staging" bits on a test server that your customers/testers/etc can play with; as well as "dev" bits on a development server
I'm fully aware of the benefits of source control. I've got daily backups of my entire development environment, so SVN would do very little to help me at this point. If the system crashes, SVN will return nothing. So, this isn't a point to be argued. This entire environment is a test environment. Absolutely nothing is nearer than several months from being available for even an alpha test. When that time nears, it will all be placed under SVN.
The constant in question points to the /assets/js folder. If I remove it, none of the javascripts stored there work any longer.
We all make mistakes. You rewrite a bit of code to be more efficient, and suddenly some use case doesn't work anymore. But if you can't remember the old code, then what?
The solution? With SVN, you just look at the last revision and see what you've missed, or roll back. Without it? You're stuck debugging and identifying the problem, then reimplementing a solution from scratch.
>so SVN would do very little to help me at this point
SVN would at least tell you WHEN you had changed that file to include that weird __AP_JS_ASSETS__ configuration.
You should also not put your svn repository on the same server as your dev server.
if you are doing any serious developing, source control is must. it should be one of your daily tools, just like your IDE is.
Kmeirlaen, you're correct on that one.
However, as far as the application itself is concerned, I've already got it under project control, so if I need to revert back to something earlier, I can do that very easily. SVN isn't required to do that.
So, I'll put QCubed itself on Tortoise