Modifying in_groups to use groups for admin privileges

Posted: Tue Dec 27, 2011 1:42 pm

In http://www.ravenphpscripts.com/posts19966-highlight-.html doffer83 raised the question of how to tell which admins are logged in. In attempting to answer that Montego and I got into a broader discussion of admin privileges. Rather than "hijack" doffer's post I will start a different one here.

Basically, the issue is that *nuke's system for controlling administrative privileges is extremely dated, inefficient, ineffective and hard to work with. Requiring a separate author's table for administrators and embedding module level administrative privileges in the modules table (in a comma separated list of admins no-less) is less than a brilliant approach. At the same time, there is tons of legacy code that is based on this arrangement so we have no choice to maintain it, while perhaps offering an alternative.

Which is what this post is about. In my custom modules I have adopted an approach of controlling administrative privileges by using nsngroups. I set up nsngroups for different "sets" of privileges I want to allocated and then test whether the user is in the group in order to see if he/she should have those privileges.

This can be done at two levels: one is whether the user even has access to a single program. It is done like this:

Code:

$gname[0] = 'Board of Directors';


$gname[1] = 'memadmin';


if (!in_groups($gname)) {


   die ('access not authorized');


}

At the second level, I can use the same approach to control access to part of a screen. So, if I have an entry form where some parts are administrative and others are for all users, I can just do an in_groups before I echo out the administrative part of the screen.

The in_groups function (and an associated in_group function) are contained in modules/Groups/includes/nsngr.php. And a few of you may be saying "but wait" in groups takes $gid (group ID) as a parameter, not gname (the group name). And you are right and I've been living with that for years but recently decided to change it, at least for my systems.

The problem with passing $gid is that you are relying on an arbitrary number that will vary for the same group on different systems depending on how many other groups were defined on that system beforehand. So a group of "membership_administrators" might be group #11 on one system and group #5 on another. Even moving from a localhost to a web server environment can require changing the group number inside the code. Not good.

So, I took a look at the nsngroups code for the two functions and modified them to do this:

Code:

function in_group($gid, $gname='') {


   global $prefix, $db, $user, $admin, $cookie;


   if (is_admin($admin)) {


      return 1;


   }


   if (!empty($gname)) {  // gname takes precedence


      $gname = filter_var($gname, FILTER_SANITIZE_STRING);


      $row = $db->sql_fetchrow($db->sql_query('SELECT gid from ' . $prefix .'_nsngr_groups WHERE `gname`=\''. $gname.'\''));


      $gid = $row['gid'];


   }


   else {


      $gid = intval($gid);


   }


   if (is_user($user)) {


      cookiedecode($user);


      $guid = $cookie[0];


      $currdate = time();


      $ingroup = $db->sql_numrows($db->sql_query('SELECT * FROM `' . $prefix . '_nsngr_users` WHERE `gid`=\'' . $gid . '\' AND `uid`=\'' . $guid . '\' AND (`edate`>\'' . $currdate . '\' OR `edate`=0)')); //RN0000994


      if ($ingroup > 0) {


         return 1;


      }


   }


   return 0;


}





function in_groups($gids, $gname='') {


   global $prefix, $db, $user, $admin, $cookie;


   if (is_admin($admin)) {


      return 1;


   }


   if (!is_array($gname)) {


      if (!is_array($gids)) {


         $gids = explode('-', $gids);


      }


   }


   if (is_user($user)) {


      cookiedecode($user);


      $guid = $cookie[0];


      $currdate = time();


      if (is_array($gname)) {


         for ($i = 0;$i < count($gname);$i++) {


            $gname = filter_var($gname[$i], FILTER_SANITIZE_STRING);


            $row = $db->sql_fetchrow($db->sql_query('SELECT gid from ' . $prefix .'_nsngr_groups WHERE `gname`=\''. $gname.'\''));


            $gid[$i] = $row['gid'];


         }


      }


      for ($i = 0;$i < count($gids);$i++) {


         $ingroup = $db->sql_numrows($db->sql_query('SELECT * FROM `' . $prefix . '_nsngr_users` WHERE `gid`=\'' . intval($gids[$i]) . '\' AND `uid`=\'' . $guid . '\' AND (`edate`>\'' . $currdate . '\' OR `edate`=0)')); //RN0000994


         if ($ingroup > 0) {


            return 1;


         }


      }


   }


   return 0;


}

I am open to suggestions about fine tuning this. But basically I have introduced $gname as a second parameter, which takes precedence when it is used. I thought for a while about passing $gname delimited by '-' (the dash character) but that could be unreliable is someone named their group, for instance, 'membership-administrators'. So, I require the calling program to push multiple groups into specified elements of the array.

I thought too, "we really don't need two functions, the functions should be able to detect whether more than one group is being passed in and respond accordingly". So we'd just need really in_group or in_groups. But again to respond to legacy and compatibility concerns we need to keep both anyway. So, I left auto-detection out.

In short, using this approach gives you an alternative to the standard "system" of *nuke administrative privileges and allows you to fine tune access to the whole module, to parts of it or even to individual parts of a screen or reports.

Posted: Tue Dec 27, 2011 7:22 pm

That would probably work ok.
I haven't look at (or even used) Groups for a very long time but in an ideal world, for user management, you would have the main user_table linked to two others;
user_group and
user_permission
Obviously user_group would hold group name and a unique id, whilst user_permission would hold a unique id and list of permissions e.g Super Admin, Admin, Editor, Moderator or whatever is needed.

We have most of these ingredients already but essentially what is needed is for whatever KEY is being used in the nsngr_users table to be part of the actual nuke_user table. This would allow you to directly add/modify a specific users group directly, rather than having to find the user in nuke_user, then do a lookup in nsngr_users and then yet another look-up to see what group the user is in.

Any way, I digress because I've had this debate before Smile

Would it not be easier to just write a new function to retrieve the group name based on the ID if that is all you need?

Posted: Wed Dec 28, 2011 8:40 am

Quote:

Would it not be easier to just write a new function to retrieve the group name based on the ID if that is all you need

That is essentially what I have done in the proposed re-write of in_group() and in_groups(). I have extended the functions to look up the ID if a group name is passed in but to use the ID directly if that is what is passed in. This maintains backward compatibility (anything that calls the old version of the functions should work unchanged) while allowing a developer to also pass in the group name and override the old method. Seems to me to be the best of both worlds and avoids adding YET ANOTHER function.

Worth noting again that this method of controlling privileges can work perfectly well right alongside the older methods.

Also, while coming up with a fuller user_groups_permission system is a noble goal, as is rewriting the nsngroups administrative function (ummm, try adding users to groups if you have more than say 100 users), those of us with grey hairs probably will never see it done. My proposed method assigns permissions "implicitly" as part of writing the module code and doesn't require any re-working of older code. Want a couple of radio boxes on a form that only an admin sees? Just check if the user is in the appropriate group and echo 'em and don't echo them if the user isn't. Couldn't be more simple.

Involved Joined: Jul 03, 2006 Posts: 273

While this approach is simple and elegant it is not perfect as the Nuke permissions system needs an overhaul to begin with but I that said I really like the solution. I would recommend implementing it for a version or 2 release of nuke and fading out the old admin system and convert all existing (Required) modules to utilize groups permissions and then encourage users to do the same this way in a couple release you could drop the old system. Backwards compatibility should not ALWAYS be a priority. Progress and improvement should be. So for now offer this solution to maintain that compatibility with the intention of removing it in the future.

As I say though I really like this approach and it will make new module development move towards group permission definitions instead of the old antiquated method.

Posted: Wed Dec 28, 2011 4:23 pm

Thanks Duck.

It happens that I was looking at the code for two custom modules that I have implemented and how privileges are managed. One is a purchasing module to let users buy things through Paypal. The other is a bike club membership module. The purchasing module I had set up the "old" Nuke way. Now, since we all tend to be forgetful let me review that. You add a author name to the author's table for any "user" who will have administrative privileges for that module. When you do that, the authors program modifies the modules table for the record for that module and adds the admins name to the admin field. Admin names are stored there in comma delimited format.

Then In the /module/Purchase directory there is an admin subdirectory which has case, links and an index.php files. The overall admin.php program runs this code:

Code:

   $result = $db->sql_query('SELECT `title` FROM `' . $prefix . '_modules` ORDER BY `title` ASC');


      while ($row = $db->sql_fetchrow($result, SQL_ASSOC)) {


         if (is_mod_admin($row['title'])) {


            if (file_exists(NUKE_MODULES_DIR . $row['title'] . '/admin/links.php')) {


               include_once NUKE_MODULES_DIR . $row['title'] . '/admin/links.php';


            }


         }


      }

This is from the upcoming 2.5 release but earlier releases are not substantively different.

Based on this, the person who you have given admin privileges for the module will have the ability to run any functions in the admin/index.php when he is signed in administratively. The drawback of this is that often you want people to run modules for you but they don't want to (and just won't) remember a separate login and where to go for it.

If we wanted to use the groups approach to determining module administrative rights, all we'd need to do is agree on a naming approach (convention) for groups having such rights and then modify the is_mod_admin function in mainfile to pick up on that. For instance, call the group who has administrative rights to News something like "module_admins_news". You could do this directly in admin.php too but the better approach would be to build it into the is_mod_admin function.

This approach would essentially "work-around" the need to assign admins to the authors table. You could even have a group called "superusers_admins" or something like that and recognize superusers from that group.

I see no problem with maintaining backward compatibility where we can without twisting ourselves all up in knots. There is tons of legacy code out there that someone, somewhere uses and I honestly don't see where the RN team is EVER going to get the resources to convert that, nor honestly would it make much sense.

Posted: Wed Dec 28, 2011 4:48 pm

For custom modules, I don't see any problems with this. There are of course other reasons why you might want to add admins to the authors tables e.g. they normal get to use a different toolbar within nukeWYWIWYG editor or you might wish for them to be able administer modules BUT there is no reason why your method couldn't be employed to do this as well as it is essentially doing the same thing i.e. looking up permission based rules and determining what happens based on those permissions.
There are many ways to skin a cat (metaphorically speaking).

Quote:

The drawback of this is that often you want people to run modules for you but they don't want to (and just won't) remember a separate login and where to go for it.

Totally agree!!
That is just one of the good and justifiable reasons for scrapping the authors table completely and and just have one 'user' table with a roles and permissions system.
Advertising client log-in is another - why the heck do they need their own seperate log-in?

Posted: Wed Dec 28, 2011 5:37 pm

fkelly wrote:

There is tons of legacy code out there that someone, somewhere uses and I honestly don't see where the RN team is EVER going to get the resources to convert that, nor honestly would it make much sense.

People using legacy code can stay with legacy versions of the system if they want to but if you notice there are not many "progressive" Cms's out there that guarantee backwards compatibility moving forward. Even forum software alone is the same! Thinking you must cater to the stragglers keeps you from making leaps and bounds forward and only making small steps. In many ways "nuke" (raven or otherwise) is already way behind the competition in the CMS world. Not willing to drop compatibility in favour of progressive architecture will only serve to widen that gap.

Therefor initiating a new standard of new module development to adhere to the practice of group permission definition is wise to begin. Then for v2.6 you start converting the core to use it as well and as the whole core get's switched over by 2.7 (or likely better call it 3.0) Old support is phased out and the new beast is born. There will no longer be a need for legacy code at that point and for those that there is, well, nobody is telling them they have to upgrade to 3.0?

The whole admin system has always bothered me with nuke and one thing I thought of is if you're going to go to the trouble of a separate Admin table why does it have the regular prefix? I mean there is a "users" prefix but not an "authors" prefix which would serve even better to protect simple SQL injection queries against it than it currently stands and I have often considered switching the system to work that way. It would be a tedious but simple conversion. However I like better the thought of eliminating authors table all together and so as such I don't think that is worth the trouble anymore.

Posted: Wed Dec 28, 2011 6:02 pm

fkelly, from what I have read and understood to this point I think you are putting to much significance into the "groups" name. We should not have to interpret a groups name to determine what it is used for. We should be determining what groups a certain user is in and then searching certain flags/keys to determine if they have access.

Have you thought about having "private hidden" groups the way PHPBB does so that we can assign individual permissions?

Posted: Wed Dec 28, 2011 7:19 pm

I am not sure fkelly is as concerned about groups name as Guardian is actually but it is because currently nuke does use the name in places that moving forward is the concern instead of as you are saying a proper permission system based on a user group id (not name) visibility of the group is a separate issue I would think. The key though is the eye on the future with the knowledge and belief of dropping legacy support in favour of a better system.

Posted: Wed Dec 28, 2011 9:07 pm

Long term Palbin you have a point. Permissions should not be an attribute of the group name but associated with the name (and of course with the group ID). We would want to do a lookup on the group name and then see if the group has those privileges. So in say my membership system I would have a set of privileges that I might call "membership admin privileges" and the membership administration group would be associated with those privileges. The membership module would test whether membership administration privileges were present. There could be several groups that had those privileges. A group could have one or more sets of privileges ... or none.

My current approach was not designed to be long term or the final word. I didn't want to change table definitions or affect in any way any of the current functions. In fact, the changes I suggested early in this thread would really need to be regression tested beyond what I've done so far.

To take this further we need to flesh out the design. I think we'd want some kind of inheritance for groups and the ability to have groups within groups. So a group that belonged to a higher level group could inherit the privileges for one thing. And we'd need to completely rework the user interface for nsngroups.

What I've suggested is just a start but it is also an approach that can actually be used for productive purposes now. I will need to look into the PHPBB approach, I am not familiar with it at all.

Posted: Thu Dec 29, 2011 7:57 am

I have suggested for a long time that a fresh new clean and clear API be started for RN. The hardest part is to step back from all the tweaking, and think it through. Put the overall framework in place with the first couple API's, this one probably being one of the most important, and then build out over time and with clear purpose. Document those APIs clearly in the Wiki and/or in phpDocumenter format for module developers to follow.

It may also be possible to rationalize through all the main current key functions used throughout all the modules, and just create one small "compatibility layer" that can be called into action once one of these functions is needed. Some of these would end up just being a "stub", an interface really, into one of the newer API calls.

I would also highly recommend starting to use OOP for the APIs go forward. It would allow you to create cleaner interfaces to the APIs plus give you the flexibility to refactor things around underneath, extend or provide additional interfaces between say internal vs. external "consumers" of the APIs.

I suggest creating an object around the user. Upon authentication, populate the object with the user's needed data (minimum need would be what is used most often, such as a few user table attributes plus groups/permission - other, lessor used, data could be retrieved later if worried about memory consumption). Then expose key methods through an interface.

I'll try and post my functional thoughts around what I would like to see in a User Authentication, Privilege and Administration API.

Posted: Thu Dec 29, 2011 10:23 am

This is more the type of system need for permissions:

http://phpgacl.sourceforge.net/

One that uses ACO's (Access Control Objects: Page level permissions) ARO's (Access Request Objects: The users and groups but can be set to anything like IP, Browser, Machine etc even technically another ACO eg allowing one module to talk to another) and AXO (Access Extended Objects: Further fine tuned control below the page levels into single records etc).

As Montego suggests though even beyond this nuke needs to be converted to more OOP design approach for extend-ability and a common Framework API implemented. Then new developments could be faster with less headache and patchiness. Now the question is: Should that be built from scratch or should it be done from an existing framework like Yii or Kohanna or Cake or what? Ihave studied several recently and my 2 top picks for frameworks are Yii and Kohana. I think Kohana is like more efficient but the learning curve and external module addons for Yii are better.

Posted: Thu Dec 29, 2011 10:54 am

Quite honestly, if we are going to thoroughly redo RN I would question whether:

- we aren't reinventing the wheel
- there are anything like the resources and expertise we would need

There are several CMS's built on Kohana for instance. How about if we took the approach of evaluating these (and other candidates) and then work up a conversion of existing RN data (stories, content, calendar, reviews, comments etc.) to whatever system we decide on.

I am not questioning the expertise of the developers that we have involved but building a CMS is a full time job (and a half). I took a hack at fixing the filtering just for the news module for 2.5 and the deeper into that thing (the news module) I got the more I despaired. Just take a look at the duplication of functions in news/admin/index.php for instance and/or the fact that the original authors simply duplicated comments.php code over into the surveys module so that after you fix up comments in news you are then faced with fixing the same thing (almost) in surveys.

It would probably be easier to just start from scratch and if we make that choice we should seriously answer the question of whether we aren't reinventing the proverbial wheel.

Posted: Thu Dec 29, 2011 12:09 pm

that is the problem with nuke all that duplicate code spread throughout. Some if duplicate function but different code even. What makes nuke attractive (at least to the current surviving developers) is it's simplicity in grasping its coding concepts. The code is aimed at the beginner php coder and is easy to comprehend and add to and modify to customize. More advanced CMS are based on OOP which many nuke coders do not have an expert understanding of. Mostly just basic so it frightens them to delve into the more complex. Not to mention that even if they understand the coding enough the way some of these CMS's operate are quite complex themselves leading to even more confusion. I myself have begun using other CMS's to do most s**t but let me tell you the learning curve can be frustrating sometimes. However I am discover as I plod through and take the time to learn I keep finding more and more things that excite me and make wish to leave Nuke behind altogether. (to be honest I somewhat have) but part of me from the basic "first love" nostalgic reason wants to stay and improve it. But it really is a lot of work and in many ways the re-inventing as you said. A conundrum indeed!

Posted: Thu Dec 29, 2011 12:16 pm

I wouldn't recommend using a ready-rolled Framework for several reasons;
1 it probably has too much stuff in it we wouldn't use so is essentially 'bloat'
2 it could become a maintenance headache if there are major changes to the framework, which might potentially require a lot of core file editing
3 not everyone is familiar with MVC methods (look at how many people struggle with something like forum templates) so there is the risk of reducing the number of current developers writing third party modules

Posted: Thu Dec 29, 2011 12:42 pm

Bloat is arguable especially when you compare the multiple redundancies in nuke. Too me thats huge bloat. I think by bloat you are referring to the argument that perhaps a class uses more memory than a procedural function which is sometimes but not always true but then it could also be argued that in some cases that those classes save on other resources l(like clock cycles) to compensate. As for point 2 that is probably less true than it currently is because a well designed oop framework is extensible by design so when the core changes rarely should it affect user customization's. So ultimately you are far better off with a framework for that reason. The last point may be the only one with some arguable validation however in truth it may also have an opposite effect of what you think. Simply because code is more reusable in a framework development time becomes reduced. Take for instance Yii framework - Even an end user with no programming skill can quite easily create a new module from scratch because all he has to do is design the table fields he wants to store data and point Yiii at the table and whamo Yii automatically creates an Add/Edit/View/Delete set of pages for the module without the user having to write one single line of code. Of course for a really advanced module coding would be necessary but you can see how much time could be saved when you don't need to even write formal queries and and how you can take the results of a query and send it to an auto page builder to format the output without you have to code and recode that same stuff over and over again.

Posted: Thu Dec 29, 2011 12:53 pm

Also note MVC is really easy to understand actually. And again for module development in can increase more people developing modules because in the community sometimes there is designers and sometimes their are coders and sometimes they each hate the others chore and can't do the other as effectively as those who like it. With the separation of Presentation into the VIEWS the coder can work together more easily with a designer to produce a module reducing each ones burden and stress. I can design and code (I code better than design but some days I can design well) but whenever I am in either mode I hate doing the other. When I am coding I would like to stick to coding and have someone else design the template. The same is true of the opposite sometimes when I am being creative and designing I don't want to break that mojo flow and go into coding. But when coding for nuke I have to always account for both. FOR MVC I just build the code and either let someone else worry about the output or wait till I am in the mood and play with the output as ready. Focusing full attention at each times on one or the other and not being divided in the middle all the time. That's why I have several unfinished nuke projects because after troubleshooting code all day I just don't have the desire to screw with CSS issues and crap to finish the module, But I also can't really push forward with it until both areas are done. MVC reduces that likelihood.

Posted: Thu Dec 29, 2011 1:35 pm

Quote:

So ultimately you are far better off with a framework for that reason.

I would have to disagree. I am involved with some CMS that use Frameworks, Ionize CMS for example, which uses CodeIgniter.
When the decision was made to move from v1.x to v2.0 of the CodeIgniter framework there was a ton of changes required to the CMS core code.
Whilst Frameworks have there uses, it really depends on how you use them.

Posted: Thu Dec 29, 2011 2:43 pm

Well haven't played much with ionize but my last look at codeigniter was far more inefficient than other frameworks but that's neither here nor there it doesn't matter whether it is Nuke's patched Procedural system or Codeigniters OOP Framework if there is a major version overhaul then compatibility gets broken no matter what. However the chance for some code staying relevant going forward is much greater in OOP than the way nuke does it and that is 100% guaranteed! I use a cms that has constant updates to it all the time I can customize modules etc without the worry of it rarely breaking my customization's and if it does it is much easier repaired than it would be if it were nuke. Why? Well let me explain:

They use a source folder for the core stuff (including built in module blocks templates etc) and then you add customization's to stuff by putting it into a folder called custom_(whatever) so to give you and example lets say they had a module called ecommerce to sell products on it would be under sources/ecommerce but I decided well it doesn't have functions for digital downloads and I want to be able to do that so I code some functions for digital downloads and now I place it in custom_sources/ecommerce so later when they upgrade the pricing system in the ecommerce to include more currency options I can upgrade my system but it doesn't touch or effect my addon at all. Everything still works. And that is just by extension but I can also do overide whereby I copy the entire original ecommerce into the custom directory and incorporate all my changes and then no matter what happens to the original source by them my system will always work. OF course a major core change that affects ALL modules and EVERYTHING in the site may break some s**t but that is the same as nuke or any CMS. But it terms of major stability in development you can't beat a good framework hands down.

Think about it you said from 1.x to 2.x Tell me one thing that works in raven 1.x flawlessly that works in 2.x (without repair that is) chances are not much and if it does then maybe there shouldn't have been a 2.x maybe it still should have been 1.13 or something. Front version numbers are supposed to signify MAJOR CORE change and compatibility breaks are to be expected. That is progress. But you'lll also notice that often to change one little thing in nuke (to say improve a module for 2.2 over 2.1) then you gotta fix other s**t in other places too cause it is all patched together slap happy. And at the very least to replicate a good change across modules you gotta copy and paste and do more coding redundantly. As exampled above. Redundant code for News comments, Surveys Comments etc etc instead of a comments API that news surveys and everything else shares so when you improve the comment system by adding 10 lines of code you do it one place once and everywhere enjoys the change instead of you having to go hunting in every module and copy and pasting (and probably further troubleshooting and repairing because of small differences) over and over. Sorry but you can never argue that behind a CMS that running at least a rudimentary framework and API does not have significant advantages over the way nuke does it. No way Josey!

Posted: Thu Dec 29, 2011 3:44 pm

I wasn't debating the point that using an series of API's or a Framework doesn't have advantages. The point I was trying to make (and clearly failed) was that retro-fitting a full blown third party framework like Zend, Yii, Kohana, CI etc into *nuke is probably not the most efficient path to take given the fact you would be reliant upon that third party framework. Likewise, taking a framework and re-writing RN around it.. well it wouldn't be RN as wek understand it today, it would be a completely different animal.

RN in it's current form would IMHO get most benefit from rolling it's Framework/ series of API's because it is then in full control of all the code and both the Framework/API's can be adapted as the rest of the cores needs demand it.

It really depends on how the RN development team see RN adapting to future needs (or even current needs come to that). Is it better to retain backward compatibility with older themes/modules (after all, this is one of the things that made *nuke so popular), or do you slowly break backward compatibility and hope developers remain interested in the product when they have to constantly adjust their code or do you just go with a completely new product?
In the case of a new product, will it have the same appeal as the old product? What advantages will it have over the dozens of other cutting edge CM already out there?

Posted: Thu Dec 29, 2011 4:22 pm

Let me throw in a third option. Those of us who have run RN sites for a while have a huge investment in DATA stored in *Nuke MYSQL tables. That data is valuable regardless of what software framework it runs in. How about picking a CMS/Framework that is fairly cutting edge, well supported and that has its own modules that are analogous to the ones currently in RN and providing conversion scripts to move the Nuke data over?

Also, as I have looked around over the last year: there are frameworks (Codeigniter, Kohana for instance) and there are CMS's and there are CMS's that are built on frameworks. If you just start with a framework you are really starting barebones. It really, as Guardian says, doesn't make sense to take a framework and rewrite RN around it.

If you look at some of the CMS's out there: Joomla, Drupal, Expression Engine, and WordPress to name 4, you see that there is quite an industry centered around writing modules or add-ons or whatever they are called in that CMS. Some are free but with many you have to pay for more than the basics. Two modules that I would pay for are a reliable Ecommerce engine and some kind of email management software. I would also place a high priority on finding a CMS that has good user and group management including associating privileges with groups.

Posted: Thu Dec 29, 2011 4:38 pm

Rolling RN around another Framework I would think pointless or at least more headache than worth. My thought was (If you want it to still look and feel like RN) is begin molding it into it's own framework.

Rewrite YourAccount to use a "user" Class.
Develop or incorporate a templating system. (And who cares about old theme compatibility 98% of them are shite anyway, full of validation errors etc. They can always be updated rather easily if the new templating system is effective.
Rewrite Permission handling system as we've been discussing
Set up a set of Standard Classes and functions that are used ineroperably through the site. IE Make a Ratings, Comments, Image Handling classes and replace all modules that use these types of features with them. Variable validation classes and html output classes. Redsign Query system to remove coding redundancies and or streamline development. By this I mean you just trow at it values and it knows what to something like maybe
$db::table(users);
$db::insert(Guardian, noob, nice, knucklehead, knickerbockernine fan);
or think of it this way:
$userArray = array(array(Guardian, noob, nice, knuclehead, knickerbockernine fan), array(Duck, dumb, diick, debbieandthedubutants fan))
$db::insert($usersArray)

I mean I am just showing one little thing but as you know I am sure from playing with other CMS's or frameworks there are far more efficient ways of doing things.

I think if you want to keep the appeal of RN that appeal is simplicity. Improve the core to be more framework like but don't over inundate users with too advanced options that the CMS looks like Drupal or some other confusing crap.

Posted: Thu Dec 29, 2011 4:58 pm

@fkelly well as far as I am concerned you can't beat this one http://ocportal.com/start.htm in terms of a CMS with a framework behind it and it actually has importers for all kinds of forums and CMS's including "Nuke" and you can choose to run their native forums (which are awesome as far as I am concerned ) or pluginto any number of forums from phpbb, invision, smf etc As I say I am basically moving away from nuke myself to this but there are somethings about nuke I miss and the learning cure is a little big but I keep pluggin away and as I do I learn more and more cool stuff about it. Nuke doesn't even come close in terms of power of what this can do and development is much faster there. That's not to say I wouldn't work on some nuke stuff too if need be but I am drifting further and further away as does nukes capability to keep up with the times

Posted: Tue Feb 28, 2012 4:22 pm

duck wrote:

Rolling RN around another Framework I would think pointless or at least more headache than worth. My thought was (If you want it to still look and feel like RN) is begin molding it into it's own framework......Develop or incorporate a templating system......

duck, Do you have a template system you like and/or recommend?

Posted: Tue Feb 28, 2012 5:06 pm

Honestly, if you want to reduce to a simple templating system I have only played with Smarty and Savant before as strictly templating engines go that aren't built into a framework or CMS already (and even some have those) so I don't know if I would be able to give you a good recommendation of a standalone engine. But here is a nice list of which Dwoo looks promising or maybe Tiny But Strong if you want to keep in "Nukes Simplicity" genre.

http://www.webresourcesdepot.com/19-promising-php-template-engines/

Right now I am working on an importer for RN version 2.4 (and 2.5 actually) to the ocPortal I mention as the new version 8 of that system is coming out soon and it looks to be even more awesome with a ton of Social integration stuff and other cool features. As a CMS goes it will probably be too complex and/or overkill for a lot of RN based projects but for some it might be an ideal upgrade from RN to manage certain sites. I know most of my sites I am switching to it. But there may be some I leave in Nuke.

I would like to see the RN team adopting ideas used in that CMS in the future but I hope they also find ways to keep it simple as that is its niche.