Simplifying RavenNuke(tm) upgrades

Posted: Tue Sep 01, 2009 1:56 pm

Yes

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

So why not just say that? Smile

Posted: Tue Sep 01, 2009 2:04 pm

No it is ok for me .. i have no problem with it.. i just think it is funny.
For me 0 is nothing so RC 'nothing'. (infact i even tought it was ment to be funny)
However microsoft used the term RC0 aswell for theire windows server release and theire silverlight.

Involved Joined: Sep 15, 2008 Posts: 352

You can't read minds they may alter files who knows. Keep it simple is all I'm saying....
I guess that's why there's 1000's of CMS's out there....everyone has a different way of doing things.

Posted: Tue Sep 01, 2009 3:37 pm

as for these different way's.

I still believe abouth to not touch core.
I also believe in a php-nuke version where all OLD modules/blocks/themes NOT work anymore , and yes... have to be "updated".

we shouldnt forget nuke is mainly based on the phpbb2 forum functions and db abstraction layer.
A discussion on this forum once went into pluggeble forums , so no forum comes with ravennuke.
When FB made smeego , he took out (all) the forum stuff , and let relay al on the index.php.
What is infact a good methode.

And one verry important ( and never seen used but was alway's there) is the funtion to load a module from within the theme/your_theme/modules folder.

Quote:

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?

For captcha:
Phpbb3 made it so that infact you can choose what captcha type you want to use , couse it is a MOD.
oscommerce have a simular approach , they uses SERVICES.
And so having all current cms's/blog's/forums etc etc , theire own methode.
Except (raven)nuke dont have it.
Now i dont blame the devellopers here , i mean .. i not say i do or i am better, couse i have nothing to offer to them.
but i have vision.
And aloth before me had aswell.
It isnt normal that 1 of the biggest community excisted (cms based) on the net suddenly are reduced to just a fragment of all current comunity's.
Howe many times readed...FB delivered a SH*T version once again.
Security once again failed on the new php-nuke etc etc etc.
But no one ever realy did BETTER as him, oh yes... an addon called sentinal.
I have installed now i think all popular cms /blogs/e-commerce aplications.
And never seen something like sentinal , simply couse it is not needed on them.

But to not sound so negativ.
I really like to work with nuke code , and i really would like to see a reconisable code of nuke in a web 2.0 enviroment.
I also respect the work and effort made to ravennuke , even if i not agree to theire methode's.

Posted: Tue Sep 01, 2009 3:49 pm

Thanks for that (I think). Now, let's stay on topic and focus on the issues that make upgrading versions more difficult or painful.

Posted: Tue Sep 01, 2009 4:07 pm

ok... upgrading issue's;

account stuff:
function is_user
function is_admin
function is_group

theme stuff:
function themecenterbox
function render_blocks
function blocks
function blockfileinc

and so on and so on... al inside the mainfile.php , things i personaly would see seperated from it.
A file what often requires changes to these functions, and noticable in all previous nuke(forks), dev's excuse to theire downloaders they had to make a change in it,for theire script get to work.

The deversity what could be changed to these kinda functions is to immens , to let it act as a ruler of the whole script.

A good funtion within the mainfile is for example:
function filter_text
it is a common used one , the whole content is text, it make sence to have it in the mainfile.php

there must be in my opinion made a difference by the dev's FIRST, to what things going to be changed frequently and what things stay in place/untouched , by theire end users.
And once decided that, and adapt the script to it , you can ask abouth pain in upgrading or difficult.

Or even better , you dont have to ask anymore at all.

Posted: Tue Sep 01, 2009 6:07 pm

Are you suggesting that the account and theme functions must be changed with an upgrade? I'm sorry, but I don't understand.

Let's try again. Which files must you manually change when you do an upgrade?

At this point, I'm not looking for solutions or suggestions, just trying to understand what problems are caused by upgrades. Maybe we've already uncovered everything, but I'd like to hear from some others.

registered · Posted: Tue Sep 01, 2009 6:42 pm

wHiTeHaT, are you suggesting we should predict the future? i don't see how we can decide which part of mainfile.php stays in the core and won't be changed by end-users. I wouldn't like that to change.

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

wHiTeHaT, unfortunately we are experiencing a language barrier issue. I know you are trying very hard to get your points across but it just isn't working Sad

. It would really help if maybe you could get someone to help you with your Dutch to English translation, especially for this thread. Thanks!

Posted: Tue Sep 01, 2009 8:45 pm

The only real problem(s) is if someone mods the language files, core files/modules or core themes. The easy solution is obvious.. Just back up your work upgrade then put your modded files back.

But what if theirs major change in a release and the mods no longer work then your back to the beginning.

So how to work around this? Maybe have more options in place to mod from admin instead of directly to the core file.

"Everything you see the script output you should have the ability to turn on or off in admin.

Example: Turn off the date an article was published or change the author name to another alias, Override the language files in admin etc....

Posted: Tue Sep 01, 2009 8:58 pm

OK, so for the article information, that could possibly be addressed by more flexibility in the news module.

What about when you add modules (as opposed to customizing)? alien73, you've done that...what are the typical changes required to support modules?

Posted: Tue Sep 01, 2009 9:33 pm

It depends on changes in the core or a Module that needs to be Ravenized and secured.
Please elaborate....

Posted: Wed Sep 02, 2009 7:57 am

Quote:

Which files must you manually change when you do an upgrade?

Mostly:
mainfile.php

Quote:

wHiTeHaT, are you suggesting we should predict the future? i don't see how we can decide which part of mainfile.php stays in the core and won't be changed by end-users. I wouldn't like that to change.

Yes , in a logic way you must try to predict the future.
You must keep the code inside what "NEVER" going to be changed.
And put the code what is mostly changed by the users ( by 10 year experience with nuke you can tell) , into the correct files/modules.

PS: i'm sorry but i dont think that my english is that bad.

As for one point i was verry clear.
Before there was asked how to keep your personal module alive/untouched when upgrade.
The answer is: put it in your theme/$theme/modules/YOURMODULE .
Nuke already have the function to keep your customized module.

Posted: Wed Sep 02, 2009 9:00 am

For the authentication functions (is_user, is_admin, etc.), I'm not convinced it's a good idea to change these. Maybe we use authentication classes, and have a way to override that for the very few sites who need alternate authentication methods.

For the theme functions, I agree that the presentation should be moved from mainfile to the theme, but the functions themselves should remain (either more flexible to allow themes to control presentation or changed to classes which could be overridden by the theme).

Posted: Wed Sep 02, 2009 9:48 am

it is good you mention classes.
Dont get me wrong removing completly the functions.
I ment removing them from the mainfile.php

Posted: Thu Sep 03, 2009 8:35 am

This is the problem with legacy coding it really complicates matters the bigger a project gets. If Nuke in general used a MVC type framework we wouldn't be discussing this but focusing on new features. But that's my opinion folks.

Posted: Thu Sep 03, 2009 8:47 am

It might be much less of an issue with a framework, but could still occur.

Posted: Sat Sep 05, 2009 4:35 pm

I tried to wade through this but I just don't understand why you need to modify mainfile.php during an upgrade.
Sure, some older modules required you to add lines to mainfile to 'include' other files but developers should be moving away from this sort of practice.
Maybe we can include a custom mainfile by getting mainfile to look for something like includes/custom_files/mainfile.php

As a developer, I constantly have to upgrade/update my development code so for me, my biggest issue is accidentally over-writing my config.php and rnconfig.php files. For me personally it would be great if we did not actually include those two files.
What we could/should do IMHO is to have;
config.php.bk
rnconfig.php.bk
in the distribution. If it's a new install, when you edit those two files, you also rename them to remove the .bk.
If it's an upgrade, you only need to worry about them if there have been changes such as extra switches like $editor_on = true and that should be indicated in the installation script/readme.

Posted: Sat Sep 05, 2009 4:42 pm

You may wish to use different authentication methods, for example. These and the theme functions that contain presentation logic / formatting are in mainfile.

Posted: Sat Sep 05, 2009 4:46 pm

My reason to strip the mainfile.php from some functions is to avoid future code improvements.

As for your suggestion i think personaly there shouldnt be a config.php at all.
I think it must be made by the installer.
for the rnconfig i could accept current state and your suggestion aswell.