[BETA] Admin Page Name Menu Override?

Are we going to be provided with a way to override english.php (or another language) to avoid messing with the admin core when registering mods for admin acccess?
OR.. Would you prefer that "mod_name.php" be added to the extra_definitions folder of the language's folder?
Would the latter effect the page_params in the admin_pages table?

I can add the sql statement for page registration and, if a file could be included versus editing a core in the admin, everything would be :bigups:

Maybe it's the drugs and typing with one hand (surgery), but I only think logically for about an hour out of every six. Have to work quick before the next drugging dulls the already dim brain.:no:

Okay, got it working with a "mod_name.php" definition file in the admin, but the brain is foggy with the database insert.

Joy of joys, the mod needs to be added to the Configuration Menu. One of only two current admin pages that uses page_params:(

In obtaining the next Configuration ID, most v1.3 mods use the @t4 to establish the ID after the item is added to the configuration_group table. This variable is then used to insert the group_id in each value addition to the configuration table.

Since this is a configuration item, the page_params item must be the group_id added to "gID=". For example, ezpages are ID 30 and the page_params is set to gID=30. That then allows configuration.php to display the menu item properly.

My thought is to utilize the @t4 combined with @t5 to form @t6 by setting @t5 to gID= and @t6 to @t5+@t4 but I can't wrap my brain around it.:frusty:

Suggestions?

Creating extra language definitions is the right way to go :thumbsup:

For registering the admin pages, including the tricky configuration page (!), here's some example code taken from Links Manager

# Clears out any pre-existing Links Manager configuration settings
SET @t4=0;
SELECT (@t4:=configuration_group_id) AS t4
FROM configuration_group
WHERE configuration_group_title= 'Links Manager';
DELETE FROM configuration WHERE configuration_group_id = @t4;
DELETE FROM configuration_group WHERE configuration_group_id = @t4;
DELETE FROM configuration WHERE configuration_key = 'DEFINE_LINKS_STATUS';

# Insert New Links Manager Configuration Group (will be indexed differently to any old one cleared out about)
INSERT INTO configuration_group VALUES (NULL, 'Links Manager', 'Links Display Settings', '1', '1');
UPDATE configuration_group SET sort_order = LAST_INSERT_ID() WHERE configuration_group_id = LAST_INSERT_ID();

# Register the paghes for Admin Access Control
INSERT INTO admin_pages (page_key,language_key,main_page,page_params,menu_key,display_on_menu,sort_order)
VALUES ('links','BOX_LINKS','FILENAME_LINKS','','extras','Y',101),
       ('linkCategories','BOX_LINK_CATEGORIES','FILENAME_LINK_CATEGORIES','','extras','Y',102),
       ('linksContact','BOX_LINKS_CONTACT','FILENAME_LINKS_CONTACT','','extras','Y',103),
       ('linksConfig','BOX_CONFIGURATION_LINKS_MANAGER','FILENAME_CONFIGURATION',CONCAT('gID=',LAST_INSERT_ID()),'configuration','Y',LAST_INSERT_ID());

This code is still being tested, but looks like it should provide a good basis for best practise for 1.5, but if anybody can improve on it, that would good to hear.

The 1.5 approach to registering pages is a big step from 1.3, specifically as a means to achieving admin user control for PCI compliance.

As such it's a delicate balance between what was required to achieve that objective and making the conversion from the box-based 1.3 admin mods as quick as possible.

The good news is that this sort of compromise won't be needed for (let's just say) future major releases. :wink:

Well.....
How about testing it where it needs the page_params like my example?
I do not have any problem with any of this UNTIL you are registering a configuration menu item with a page_params requiring a gID=## setting based on the group_id being created as the database is being updated for the mod.
Perhaps I didn't explain it well with one hand:unsure:

Well.....
Safari for iPad wouldn't let me scroll left on your code! I'll give it a go.
THANX

Ah, so you couldn't see the "CONCAT('gID=',LAST_INSERT_ID())" that inserts inserts the page_params in this example?

None of it:blink:
The concat was the trick. I left the @t4 instead of last insert id to make sure it uses the correct value since we will be allowing multiple admins. Just the paranoia in me, but it is now working on the sql side.
Will test whole package after Dr appt. Glad I don't have to drive to byte's:P

Provided there was a previous incarnation, that should allow it to be reinserted with the same ID. But if there wasn't the value of t4 may be NULL which would fail.

So you'd have to add extra processing to ensure that you have a legitimate value.

However, that's unnecessary as the mysql LAST_INSERT_ID() value is unique to the database connection, so there's no danger of different users clashing.

Kuroi,
Didn't doubt the code. Just wanted a quick "get that part of the installation going" out of the way.
When all is working, I'll readdress the database side before release.

Well I've moved a little your original suggestion. My preference now is to assign the value returned by LAST_INSERT_ID() to @t4 (or equivalent, I have a preference for meaningful names) immediately after the insert, rather than sprinkling function calls through the installation script.

Kuroi,
That too was part of my concern. The mod I'm munging has many items to add to the configuration table as well.
That could possibly mess with the LAST_INSERT_ID() as we then need to make sure the group ID is not confused with the configuration ID.
Simpler to stick with the @t4:bigups:

BTW I tested three browsers on the iPad2. None would scroll the code in either mobile or regular view.:no:

Shouldn't the install SQL also take care of unregistering the previously-installed admin_pages entries as well?

# Clears out any pre-existing Links Manager configuration settings
SET @t4=0;
SELECT (@t4:=configuration_group_id) AS t4
FROM configuration_group
WHERE configuration_group_title= 'Links Manager';
DELETE FROM configuration WHERE configuration_group_id = @t4;
DELETE FROM configuration_group WHERE configuration_group_id = @t4;
DELETE FROM configuration WHERE configuration_key = 'DEFINE_LINKS_STATUS';
DELETE FROM admin_pages WHERE language_key = 'BOX_LINKS';
DELETE FROM admin_pages WHERE language_key='BOX_LINK_CATEGORIES';
DELETE FROM admin_pages WHERE language_key='BOX_LINKS_CONTACT';
DELETE FROM admin_pages WHERE language_key='BOX_CONFIGURATION_LINKS_MANAGER';

# Insert New Links Manager Configuration Group (will be indexed differently to any old one cleared out about)
INSERT INTO configuration_group VALUES (NULL, 'Links Manager', 'Links Display Settings', '1', '1');
UPDATE configuration_group SET sort_order = LAST_INSERT_ID() WHERE configuration_group_id = LAST_INSERT_ID();

# Register the paghes for Admin Access Control
INSERT INTO admin_pages (page_key,language_key,main_page,page_params,menu_key,display_on_menu,sort_order)
VALUES ('links','BOX_LINKS','FILENAME_LINKS','','extras','Y',101),
       ('linkCategories','BOX_LINK_CATEGORIES','FILENAME_LINK_CATEGORIES','','extras','Y',102),
       ('linksContact','BOX_LINKS_CONTACT','FILENAME_LINKS_CONTACT','','extras','Y',103),
       ('linksConfig','BOX_CONFIGURATION_LINKS_MANAGER','FILENAME_CONFIGURATION',CONCAT('gID=',LAST_INSERT_ID()),'configuration','Y',LAST_INSERT_ID());  

No and yes.

No, because admin_pages was only introduced in this version of Zen Cart, so wouldn't be any prior entries to clear out.

Yes, because it does no harm and may even help in a number of edge cases, e.g. somebody running the SQL twice, and possibly for users upgrading a cart with Admin Profiles installed (haven't looked at that in depth yet).

Yes, for future updates if the settings have changed.

So on balance I'd now use:

# Clears out any pre-existing Links Manager configuration settings
SELECT @links_mgr:=configuration_group_id FROM configuration_group WHERE configuration_group_title= 'Links Manager';
DELETE FROM configuration WHERE configuration_group_id = @links_mgr;
DELETE FROM configuration_group WHERE configuration_group_id = @links_mgr;
DELETE FROM configuration WHERE configuration_key = 'DEFINE_LINKS_STATUS';
DELETE FROM admin_pages WHERE language_key = 'BOX_LINKS';
DELETE FROM admin_pages WHERE language_key='BOX_LINK_CATEGORIES';
DELETE FROM admin_pages WHERE language_key='BOX_LINKS_CONTACT';
DELETE FROM admin_pages WHERE language_key='BOX_CONFIGURATION_LINKS_MANAGER';

# Insert New Links Manager Configuration Group (will be indexed differently to any old one cleared out about)
INSERT INTO configuration_group VALUES (NULL, 'Links Manager', 'Links Display Settings', '1', '1');
SET @links_mgr = LAST_INSERT_ID();
UPDATE configuration_group SET sort_order = @links_mgr WHERE configuration_group_id = @links_mgr;

# Register the pages for Admin Access Control
INSERT INTO admin_pages (page_key,language_key,main_page,page_params,menu_key,display_on_menu,sort_order)
VALUES ('links','BOX_LINKS','FILENAME_LINKS','','extras','Y',101),
       ('linkCategories','BOX_LINK_CATEGORIES','FILENAME_LINK_CATEGORIES','','extras','Y',102),
       ('linksContact','BOX_LINKS_CONTACT','FILENAME_LINKS_CONTACT','','extras','Y',103),
       ('linksConfig','BOX_CONFIGURATION_LINKS_MANAGER','FILENAME_CONFIGURATION',CONCAT('gID=',@links_mgr),'configuration','Y',@links_mgr);

INSERT INTO `configuration` VALUES (NULL, 'Links Box - Display View All Links', 'BOX_DISPLAY_VIEW_ALL_LINKS', 'true', 'Display View All Links on Links Sidebox', @links_mgr, 2, NULL, now(), NULL, 'zen_cfg_select_option(array(''true'', ''false''), ');
.
.
.

Still playing with this, but the good news is safari for iOS5 now scrolls quotes and code left and right on the iPad2!:clap:

don't suppose anyone has looked into the upgrade for 1.3.9h to 1.5 with admin profiles installed?? Caused me a few probs with blank admin login after upgrade, but after deleting the original profiles files mamanged to get in, but now having real difficulty trying to get all my installed mods back on the menus.

personally, id run through the uninstall of Admin Profiles, then upgrade to 1.5

Test site of course, see if it worked.