Simplifying RavenNuke(tm) upgrades

registered · Site Admin Joined: Jun 04, 2004 Posts: 6437

We continue to make improvements in the architecture and upgrade process to simplify upgrades, including a table comparison utility and the ability in version 2.4 to install addons that require JS and CSS without needing to change code (which means upgrades shouldn't require those same changes).

What other issues, especially related to addons not included in RN, make upgrading to the latest version of RavenNuke(tm) more difficult?

We can discuss converting from other Nuke distributions to RavenNuke(tm) at some point, but for now, I'd like to focus on making upgrades as efficient and as painless as possible.

Posted: Mon Aug 31, 2009 3:49 pm

The biggest problem that I have upgrading every time is the custom code included in my sites.

An example is NavTap. I use a MODDED version of it to display a toolbar across the top of my sites to my logged in users and text to everyone else.

Also the way DT works is modded on my sites for use in my theme. Editing ALL of this is a major pain every time I upgrade.

All I am really doing to tapping into a $var and diplaying that $var in other areas.

I have always liked the way Gallery does their LOCAL file system. So you very seldom have to touch the core files....you just create a file called LOCAL and put your changes there. The upgrades work....and the site looks and works the way you intended.

Just my .02

Dawg

Posted: Mon Aug 31, 2009 4:07 pm

Dawg , your right.
That is the whole point where nuke and theire forks fail.
I say first things first;
Seperate the theme from the core.
No header and no footer anymore , they need to be in the theme.
The content feeding should also be free from html build up.
The theme must show the content and not the core.
The core and it's modules/plugins etc etc build the content.

Posted: Mon Aug 31, 2009 4:21 pm

I also try to understand what it means to: "and the ability in version 2.4 to install addons that require JS and CSS without needing to change code (which means upgrades shouldn't require those same changes).
".

Can you give us an example kguske?

Posted: Mon Aug 31, 2009 4:56 pm

@wHiTeHaT: We have pretty extensive documentation on the change to how RN loads JS and CSS, and that should be available soon.

But a good example is Google Analytics. Let's say that you want to use Google Analytics, which links to an external JS just before the closing BODY tag. Today, you'll need to modify footer.php after every upgrade, unless you make the change to your theme, which would need to be changed if the theme is upgraded. After RN 2.4, you can have a PHP file that contains the link to Google Analytics, and it will not need to be changed in future upgrades (i.e. you'll be able to upgrade and continue to use Google Analytics without any changes to an RN file). So, it's similar in concept to the Gallery approach Dawg mentioned above.

@Dawg:Are the NavTap changes in your theme? I'm not sure how that works, but it might help if the presentation changes are there, then you would only need to change if your theme was upgraded (less frequently than RN, I suspect).

Also, nukeSEO(tm) DH (Dynamic HEAD tag generation) will replace DT in RN 2.4. There is information here at RN about it, and demos and other documentation at http://nukeseo.com. To get the most benefit from this, you may need to make changes to your theme (once). But you can use it without changes to your theme. Can you explain why DT requires changes to your theme? Which variable(s) are you using in other areas?

Posted: Mon Aug 31, 2009 5:05 pm

Quote:

unless you make the change to your theme

told ya.

a connection to some "external" Js , in my opinion isnt a good example.
i would like to know what i must do when i want to use internal JS.
What kinda JS libary i load?
will it make a different if i use mootools.js? etc etc etc.
for now you mention an external JS.
I'm sorry i dont get it right.

But what abouth the css?
Does it mean now when i move from module to module , i can load different css for each?

Involved Joined: Sep 15, 2008 Posts: 352

Upgrading a Nuke site has always been a pain but it's getting better with Raven Nuke.

1. The language files should really be in the database so there not overwritten during an upgrade. You can always back them up but that's a hassle.

2. Custom module and theme folders away from core modules

3. A framework like Zend or Cakephp to addon features without touching any of the core.

Posted: Mon Aug 31, 2009 6:32 pm

wHiTeHaT,

Actually, it's an excellent example - just not the one you're looking for. Smile

Since you're looking for more, I'll tell you that it doesn't need to be external - it can be internal, and even dynamically generated by your included php file. You can load any kind of JS, including mootools. Same for CSS - dynamically defined / generated, external on site or off site.

Yes, it can be module specific (it can be defined by the module, stored in the module, or defined in the include to only be loaded for specific module(s).

alien73,

It's easy enough to prevent upgrades from language files, but what about upgrades to the language files themselves. Putting that in a database doesn't really change that issue...

What do you mean by custom modules and them folders? You can have custom modules and themes today.

There has been some discussion about frameworks, but how does that minimize the effort to upgrade? The framework itself doesn't ensure that - it's how it's implemented, no?

Posted: Mon Aug 31, 2009 8:43 pm

Your missing my point or maybe I need to explain better.

1. Take Drupal as an example. There's a folder for core and then a folder for custom modules. When you upgrade your upgrading the core and not overwriting custom modules. You never touch the "core" since the API/Framework allows you to modify anything or plugin to the core. "aka...Custom Modules"

2. You would upgrade the language files with the update script.

3. A framework would change everything as mentioned above... hence make updating a peace of Cakephp.....ooops I meant Cake.

Posted: Mon Aug 31, 2009 9:03 pm

The only advantage of using a separate folder for custom modules is if a custom module has the same name as a core module (i.e. you don't overwrite custom modules with PHP-Nuke if they have a different name). Is the intent that you take a core module, customize it and move it to the custom folder, keep the same name, then future updates don't overwrite your customizations? That would be OK if you did not need or want updates to the original module, but the same could be accomplished by copying the module to a new name... OK, I guess there's a 2nd advantage - you can wipe out the core folder and replace without worrying about losing your custom modules. But really, how often has that been necessary?

Upgrade the languages via FTP or a SQL update - either way, it's still updating them without regard to modifications. Toe-may-toe or toe-mah-toe... or is there a custom language table, too?

Creating a new CMS from scratch using a framework might be a piece of cake, but I'm not sure supporting thousands of existing addons (themes, modules, blocks, tweaks, etc.) and the easy ability to integrate other scripts (e.g. phpBB, coppermine, osC, etc.) that might not use the same or any framework would be easier with a framework.

Posted: Mon Aug 31, 2009 9:39 pm

You wouldn't touch the core module folder or rename anything. You also can have a framework "Cakephp" "Zend" or "role your own" and keep what's in place also. So the all the 3rd party modules would still work.

Custom language table would be needed for my idea to make sense. LOL

registered · Posted: Tue Sep 01, 2009 1:59 am

alien73 wrote:

Custom language table would be needed for my idea to make sense. LOL

It does in a certain way ,but you make it harder for translators (and devs) and end-users who need a quick upgrade or are installing a custom script.
The purpose of ravennuke is to make php life easier and not running around cpannel trying to find the sql input box for phpMyadmin.
Having a language file was a great idea and I still think we need to make some upgrades to the system.

I like the idea of custom folders for custom files. I'm eager to see how 2.4 will handle JS. I was looking the other day at the maximus cms script which is the french nuke, they implemented a system which recognize a "custom" folder in includes or in modules/You_module via an "if statement" and every bit of file in the folders are included in the header or the modules.Which makes it better when upgrading , you don't lose the custom js you implemented because the core upgrades doesn't have any "custom" folders in the package.

What would be good too is to make upgrades possible via the admin pannel and not ftp. Much more like <<I go to admin.php upload the upgrades.tar.gz , click on upgrade and tadaa. .."Succesfully Upgraded!".>> Very Happy

Posted: Tue Sep 01, 2009 4:51 am

2.4 will use addon folders at the site and module level for loading custom and non-core JS. To improve performance and minimize changes required for addon modules that weren't written for RN 2.4, the module level can also have a defined variable that specifies where the addon JS is stored. This may require a modification to the module's index file, but is intended to minimize support for that module (i.e. you won't have to make significant changes to the way that module is written or organized to comply with RN 2.4) and it will be easy for module developers to support RN 2.4 by simply adding those definitions.

Posted: Tue Sep 01, 2009 7:22 am

It's all in how you implement it. I've seen thousands of scripts with impressive code but worthless to the end user.

Posted: Tue Sep 01, 2009 7:40 am

Agreed!

So far, the pain points are:
- custom / addon JS and CSS (which we've tried to address in RN 2.4)
- forum mods
- other customizations like the ones Dawg mentioned

And, for convenience:
- the ability to upgrade via an admin page function

Again, I'd like to identify upgrade issues with sufficient detail so we can try to identify ways to eliminate, minimize or at least document how to address those issues as efficiently as possible.

Other issues / pain points when upgrading?

How about notifications of upgrades? IE, being able to see when an update is available for RN and / or for specific addons?

Posted: Tue Sep 01, 2009 8:38 am

The upgrade notification feature would be nice.

Posted: Tue Sep 01, 2009 8:47 am

Without diverting off into our "Tools to do the job" thread, I have to say that using Beyond Compare as an upgrade tool has become essential to me. You can have your downloaded (and upgraded) distribution (say 2.4) on one side of the screen and an FTP view of your current distribution (say 2.3) on the other side. You can go through your current site folder by folder comparing it to the new distribution. Where you know that you haven't made any changes to your old site's programs you can just copy the new distribution over the top of it. Where you have made modifications (customizations) you can compare the two files in adjacent windows and BC will show you each difference. You can then choose which ones you want to keep and which ones you want to overwrite.

Also, if there are directory structure differences you can see those clearly and make adjustments. This avoids the risk of leaving large numbers of orphaned files just lying around your old site.

In essence BC combines a file and folder comparison tool with a FTP tool in a very effective way for upgraders. I'd highly recommend it for anyone planning an upgrade to 2.4 when it is available.

Posted: Tue Sep 01, 2009 11:07 am

Thanks, fkelly. I also find BC invaluable. What I'm trying to discover here, though, is how to make file comparison unnecessary (and at least, less necessary) when upgrading.

registered · Posted: Tue Sep 01, 2009 11:31 am

Very excited to see 2.4 and what it offers! is there a tentative date of release on it?

jc

Posted: Tue Sep 01, 2009 11:35 am

BC is great tool for coders but no end user will want the hassle. They want plug and play. Hit a button a let the script do all the work!!!!

Posted: Tue Sep 01, 2009 11:51 am

Kguske ... less necessary would be good. We need, for instance, to rework the themes so that people can customize the header area with their own logo and have that "stick" across upgrades ... same with the list of shortcuts to modules within their sites.

Alien ... an "end user" would not have customized his site by changing PHP code so he would have no worry with just replacing the old files.

Neapolitan ... 2.4 is in the testing and release candidate stage internally. But only Raven can discuss dates and even then we never know what we are going to find and exactly how long it will take to fix any issues.

Posted: Tue Sep 01, 2009 12:02 pm

It's easy enough to copy a theme and modify the header so it's not overwritten in an upgrade. nukeNAV(tm), though not in its initial release, and other menu / navigation addons can help address the shortcut issue, too.

Site Admin/Owner Joined: Aug 27, 2002 Posts: 17088

Version 2.40.00 RC0 is slated for release - this week Smile

Posted: Tue Sep 01, 2009 1:51 pm

RC0 ? lol

Posted: Tue Sep 01, 2009 1:54 pm

What's funny about release candidate 0? Would it be better to call it RC1?