Admin Page Registration for 3rd Party Modules

@ Dr.Byte
Yes, that is what I remembered. Sounds great and thanks again for all the work.
There is no problem with the method Conor and Kuroi have explained so well. I just wondered if a quick fix was worth it but probably not if we are looking forward to a shiny new architecture.
Thanks again

Is there a manual for using Admin Page Registration somewhere.
Telling you how to do the settings and what need to be in the filling in. I have been using v1.3.9h and I am still using it on another store, but I am doing a new store in presently using: v1.5.0 and I am loss.

If you use mods that have been upgraded for 1.5 you don't need to use this page at all.

If you use mods that haven't been upgraded, there's an explanation for each field on the page itself, but remember too that the mods that haven't been upgraded probably won't have the same level of security as the 1.5 code to which they're being added.

kuroi:

If you use mods that have been upgraded for 1.5 you don't need to use this page at all.

If you use mods that haven't been upgraded, there's an explanation for each field on the page itself, but remember too that the mods that haven't been upgraded probably won't have the same level of security as the 1.5 code to which they're being added.

Which is why some of us need a manual. I want to upgrade the unsupported Event Calendar but have no clue where to even start.

I think what Kuroi is trying to say in his usual lovely way is that it is one thing getting it to work and another getting it to work and making sure that it meets the security standards of Zen 1.5.

Some mods may just work if the sql is adapted.

Some mods may need some work on the code itself to get it to work with 1.5.

Some mods may need major restructuring to work with Zen 1.5.

A few mods may never work with 1.5.

If you are qualified to make the decision as to which scenario you are in then it would be great if you took on the updating of a module. There are a lot out there that need to be done. However, it is usually best / easiest if the author of the mod decides what work needs to be done because they are hopefully most familiar with the code. Of course this is all open source so the community will work together to make things happen but it is not quite as simple as writing a quick manual as the actual code of the module needs to be evaluated.

Hi Niccol

Thanks for the clues. I am sure (to mix a few metaphors) that at the end of the day it will all turn out in the wash!!!

Cheers

I'm like chadderuski I can add it manually to the configuration menu but if I add a sql statement it throws and error. This is the sql statement I'm trying to get it to add. This happen in store admin and phpMyAdmin. Any ideas why. Thank You in advance.

# Register the configuration page for Admin Access Control
INSERT INTO admin_pages (page_key,language_key,main_page,page_params,menu_key,display_on_menu,sort_order) VALUES ('configRewardPoints','BOX_CONFIGURATION_REWARD_POINTS','FILENAME_CONFIGURATION',CONCAT('gID=',@groupid),'configuration','Y',@groupid);
```This is the error it throws 

**Error**

     **SQL query:**     
INSERT  INTO admin_pages( page_key, language_key, main_page, page_params, menu_key, display_on_menu, sort_order ) 
VALUES (
 'configRewardPoints',  'BOX_CONFIGURATION_REWARD_POINTS',  'FILENAME_CONFIGURATION', CONCAT(  'gID=', @groupid  ) ,  'configuration',  'Y', @groupid )
 **MySQL said: **[\[IMG\]https://p3smysqladmin01.secureserver.net/p50/333/themes/original/img/b\_help.png\[/IMG\]](http://dev.mysql.com/doc/refman/5.0/en/error-messages-server.html) 
  #1048 - Column 'page_params' cannot be null

How are you establishing @groupid? It is probably a null or unrecognized by concat.

Rather than try to establish a variable the method I used was to put a SELECT in where you have @groupid. Since the gID and comfiguration_group_id need to match in number, what about something like the following:
NOTE: this a method I would use to register admin pages in the CONFIGURATION menu.> INSERT INTO admin_pages (page_key,language_key,main_page,page_params,menu_key,display_on_menu,sort_order)

VALUES ('configRewardPoints','BOX_CONFIGURATION_REWARD_POINTS','FILENAME_CONFIGURATION','1','configuration','Y', '1');

UPDATE admin_pages SET sort_order = (SELECT configuration_group_id FROM configuration_group WHERE configuration_group_title = 'Reward Points') WHERE page_key = 'configRewardPoints';
UPDATE admin_pages SET page_params = CONCAT('gID=',(SELECT configuration_group_id FROM configuration_group WHERE configuration_group_title = 'Reward Points')) WHERE page_key = 'configRewardPoints';The original INSERT gets the basic info into the table. I tried using SET @agrouid:=id but couldn't get it to work. I also tried last_insert_id() but since you are setting the configuration table, the last_insert_id() winds up being the last configuration_id versus the configuration_group_id.
So I tried several things and what worked for me was to establish the listing in the admin_pages table with page_params and sort_order set to 1 just to get the listing established and then came back with the update as that was the only method I could get the select to work with.
I know someone can probably point out twenty ways it can be done better, but this is what worked for me.
Punctuation is, of course, king.:yes:
Also, you will need to see if the entries I fudged for Reward Points are correct and match what is in those places in YOUR database.

dbltoe:

How are you establishing @groupid? It is probably a null or unrecognized by concat.

You know I have tried a lot of different ways to get it to work and none would work. Your way worked very well. Thank You for all the schooling. Zen Cart and there new ways of doing things. :no: I like it better the other way but I have learn now how to update a lot of the modules that are not compatible with zen cart 1.5.0 so I guess I will help in that area with the ones I use anyway. Thank You again for the help like I said it worked like a charm.

Glad it worked for you:clap:

Still waiting for the critics:lookaroun

Remember: There's a LOT MORE TO UPDATING ADDONS FOR 1.5 than merely adding menu options!!!!!
Discussed in other threads.

DrByte:

Remember: There's a LOT MORE TO UPDATING ADDONS FOR 1.5 than merely adding menu options!!!!!
Discussed in other threads.

Yes I understand that. What other threads are you talking about.

DrByte:

Remember: There's a LOT MORE TO UPDATING ADDONS FOR 1.5 than merely adding menu options!!!
Agreed!:yes:
I try each day to learn more to make sure I'm doing it right. If it weren't for the several posts on this subject, I would be in the dark myself. I still am not close to comfortable with going too far but get a feeling the "tricks" are being kept a little close to the chest.
I can understand that teaching someone to fix can lead to someone else learning to break.
I hesitated to list my solution, but was empathizing with countrycharm's pain. Certainly did not want to put something out that could be the elephant in the room later.

Nothings being "kept close to the chest". I've explained the requirements in other threads several times.

DrByte:

Nothings being "kept close to the chest". I've explained the requirements in other threads several times.

DrByte:

The addon needs to be upgraded to work with the new admin menu system in v1.5. There are several discussion threads which address those matters.
There are several more things, security-related, that are also required when upgrading modules for compatibility with v1.5. If you don't also do those things then your addons will not work either. They'll be redirecting you to your admin home page every time you click on a link in the addon.
So, merely adding menu options isn't sufficient for all addons.

OK i have read what you have said about a Module not working if the security-related issues are not fix. I'm like dbltoe I try to learn this stuff more and more each day.

The tricks aren't being kept close to anyone's chest because there are not any tricks.

The page needs to be registered to appear in the menus. This is just a hugely massive improvement from the previous system. It needs a admin page file, some defines and a correct entry in admin pages. This is discussed a lot in other threads.

For the file to work -

1. It needs to function with the Zen 1.5 codebase. That may mean re-writing or it may be a merge of a lot of files with the new versions of those files. Or it may be that no changes are needed or that the module is never going to work with 1.5. This really can only be discussed on a module by module basis.and really is not the business of the ZC core developers.

2. In it's new form the module needs to meet the security standards of 1.5. The main one of these is that ''random' use of GET parameters is going to divert you back to admin main page but using GET parameters for things like product filters is OK. There are others but my understanding is that that is the main one at the moment. All data entered and read from the database needs to be sanitised but I don't think this will break functionality but is so basic a requirement that it should be implemented anyway. If the developers can add to the list of 'no-nos' then that would be helpful but I haven't found too many new ones yet.

Of course, there may be some merit in not discussing in an open forum exactly how all the security features work. But if you create a well coded module that meets those guidelines it seems to work.

niccol:

2. In it's new form the module needs to meet the security standards of 1.5. The main one of these is that ''random' use of GET parameters is going to divert you back to admin main page but using GET parameters for things like product filters is OK. There are others but my understanding is that that is the main one at the moment. All data entered and read from the database needs to be sanitised but I don't think this will break functionality but is so basic a requirement that it should be implemented anyway. If the developers can add to the list of 'no-nos' then that would be helpful but I haven't found too many new ones yet.

Of course, there may be some merit in not discussing in an open forum exactly how all the security features work. But if you create a well coded module that meets those guidelines it seems to work.
This is why you haven't seen "okay, how do we identify the critters" and "where to throw the bleach."
It's difficult to find much that matches what I'm looking at in mods I'm trying to get working. They're not mine, but my customers use them. And I am attempting to ensure that they work while REALLY ensuring that there are no hidden glitches.
This is one of those times that I wish we could have a restricted area where a few of us could put our heads together (with supervision) on a file or files. I am an ardent advocate of education, but I also realize there are some things you don't teach until you're sure the knowledge will be used for good.
I quickly find every mention of $_GET, admin_pages, etc. but find myself searching Google for hours trying to make some tutorial match what I'm looking at from a previous programmer.

It's not as simple as, but like, telling someone to scroll down in their browser. Could they use the mouse to move the site, their down arrow, or Page Down key? Or maybe just Home or End? Everyone has their way to do things that don't match ANY tutorial yet get the job done. Seems like every tutorial I look at cries out, "Use the mouse wheel!". On a Mac?
Get my :frusty:?

@dbltoe

Yes I do understand your frustration.

Some of the codebase in Zen is quite old now. What that has meant is that code hacking has actually pretty straight forward and with a bit of php knowledge people could get modules to work. That resulted in a wide range of powerful modules that did all kinds of things and 'worked fine' . Which was a good thing. Particularly with the ethos that most modules are free.

The structure and security of these modules is not guaranteed. I know that I am as guilty as anyone of producing code that 'worked' but had its flaws.

I am not one of the developers so what I say next is just my opinion.

PCI compliance has changed the playing field. We do not need to discuss here whether that is a good or bad thing and what the flaws in the present situation are because that has been discussed elsewhere. But it is important to understand that the playing field has been changed.

It would not be all that responsible for developers of a widely used platform to continue to produce a software that facilitated people adding modules that invalidated the PCI compliance that they have worked so hard towards.

We all want to see Zen as a inherently compliant platform. We all want to see all the modules as inherently compliant. That is just part of the new world that we are operating in. Unfortunately, that does mean that there is an onus on module authors to understand a bit more about how this all works, otherwise the module may not function.

There are lots of people out there who have put in a huge amount of work trying to help with modules they know and love but did not actually write. This is one of the failings, and great strengths, of Zen, and perhaps this form of open source development. The original authors are not around any more. The management of modules has been picked up by others. So, re-writing a module is really hard work for those other people. In some cases it may just be easier to start from scratch then wade through someone else's code, which may or may not be comprehensible in the first place.

A good example of how it works when the author is still around are all Conor's mods, for instance Ceon URI rewriting. They were updated by the author and work on 1.5. Lovely.

The orphaned modules, where the original author is not around are much more problematic. And, yes, I can understand the frustration. There is one module out there that I am having a personal nightmare with. But, it really is not the developers problem that there is no-one available who really really understands the module's code well enough that updating it reasonably simple.

The problem is the level of understanding of a module's code not the changes in 1.5. Other platforms insist that an 'active' module has active 'Maintainers' ( I am using Drupal language here ) and if not then they are flagged as 'Not Actively Maintained' . I wonder how many modules in the free software add-ons section would actually have an active maintainer at the moment? Perhaps that is something that would be a good idea to implement.

Also, I have to say that this is going to change again if 2.0 is released. Modules are going to need to be re-worked again. Without any prediction about when that might happen it is hard to judge what the best line of approach is regarding 1.5.

That's the longest "I agree" I've ever read without one suggestion of a solution.:P

dbltoe:

That's the longest "I agree" I've ever read without one suggestion of a solution.:P
That's what I'm talking about.:D