Admin Page Registration for 3rd Party Modules

[niccol]

It wasn't an 'I agree'.

OK. The short version. You are trying to update a module but imply that you do not understand the module's code. Can you really not see the problem with that?

Retro-actively there is not a solution. The people who wrote the code aren't around so unless someone who understands the code updates it then user's are going to be disappointed. The module is unsupported software.

Going forward the solution proposed was that there is a maintainer, or more than one, for each module, so users know whether the modules they use are likely to be updated or if they will just create the same problem next time this situation is reached.

[dbltoe]

Could've fooled me.

You are trying to update a module but imply that you do not understand the module's code. Can you really not see the problem with that?

Is it a problem that I'm trying (willing) to do it or that you think I'm not able?

Retro-actively there is not a solution. The people who wrote the code aren't around so unless someone who understands the code updates it then user's are going to be disappointed. The module is unsupported software.

If the code were CFML, that would be a ridiculous statement but, since it's PHP, yes there are some things I need my universal translator for.
The situation I am working on is finished IF I didn't care that it's one method makes it incompatible with some SEO mods when the cart is not in the root. Would you have me just put a disclaimer in the readme or try to make it work.

Going forward the solution proposed was that there is a maintainer, or more than one, for each module, so users know whether the modules they use are likely to be updated or if they will just create the same problem next time this situation is reached.

I've never proposed this or think it would work. It's hard to get volunteers and (although we'd like) we can't appoint you to maintain all the mods similar to what you are working on. You yourself have said, "I can do this" and taken on the image handling situation.
Some of us are not comfortable with, or capable of, programming a new mod every time one needs to be modified to meet php, mysql, pci, etc, etc. We are capable of finding the code and changing it if we had a place that we could talk Zen- versus Tutorial-language.
Let me try another analogy. I have a friend that lives about a quarter mile from my house, but I have to drive 2.6 miles to get there. It's almost four miles if it has rained and the creek is flooded. Or I could just walk up the hill to his house crossing three barbed-wire fences and dealing with a dog or two. Not to mention the Donkey that guards the Barbados sheep.
Just like with the mods, I could take the time to figure out which way to proceed (is it raining?). But it certainly would help if someone pointed out a way to add weatherbug to my navigator!
I know I'm getting off-topic a bit here, but there are those of us who are trying. And, doing so carefully because we are aware of the ramifications. It would be nice to have you "sitting next to me" to point at a line of code and say, "can you tell what this guy was saying here?" Not wanting a handout, just want to learn to fish better.

[niccol]

My opinions are:

1. the person who updates a module should understand the code in that module. That is a general statement and not aimed aimed at anyone in particular.

2. my suggestion ( not yours ) is that there needs to be a 'maintainer' specified for modules.

3. it is my belief that nothing specifically needs to be done to make mods work other than remove the use of get parameters and make sure that the code works with the 1.5 codebase. This last one applies to any update.

4. If one mod is causing a problem with another mod, particularly an 'SEO' mod, then that may be a whole different kettle of fish to straight forward problems with module registration in Zen 1.5.

That's it.

And finally, we have done stuff together on this forum, so it would be unjust to think that in any way I discourage you. I admire the stuff you have done, have learnt stuff from you, and would urge you to keep it up.

[countrycharm]

My opinions are:

1. the person who updates a module should understand the code in that module. That is a general statement and not aimed aimed at anyone in particular.

2. my suggestion ( not yours ) is that there needs to be a 'maintainer' specified for modules.

3. it is my belief that nothing specifically needs to be done to make mods work other than remove the use of get parameters and make sure that the code works with the 1.5 codebase. This last one applies to any update.

4. If one mod is causing a problem with another mod, particularly an 'SEO' mod, then that may be a whole different kettle of fish to straight forward problems with module registration in Zen 1.5.

That's it.

And finally, we have done stuff together on this forum, so it would be unjust to think that in any way I discourage you. I admire the stuff you have done, have learnt stuff from you, and would urge you to keep it up.

Well beat me in the head, I guess it took all this talking to get to the point nothing specifically needs to be done to make mods work other than remove the use of get parameters and make sure that the code works with the 1.5 codebase.. Now that was easy but it still doesn't show dbltoe or me how to go about doing that. Nothing to show or compare it with...............

[kuroi]

Well beat me in the head, I guess it took all this talking to get to the point nothing specifically needs to be done to make mods work other than remove the use of get parameters and make sure that the code works with the 1.5 codebase.. Now that was easy but it still doesn't show dbltoe or me how to go about doing that. Nothing to show or compare it with...............

The topic for this thread was admin page registration. There's a worked example of GET var replacement (which isn't always needed) in this post.

[gjh42]

And what will be obvious to those skilled in SQL setup of admin configuration options, but may not be to those starting to work with admin settings, is that this is only for registration of the pages and not for the actual creation of them. What is discussed here does not replace any of the previous methods, which are well described here (post 13 especially).

[countrycharm]

The topic for this thread was admin page registration. There's a worked example of GET var replacement (which isn't always needed) in this post.

Thank You, I will take a look at this for sure.

[gjh42]

There is also a critical bit of information not addressed at all in this thread: you need to define a constant (in /admin/includes/extra_datafiles/) for this (adjusted to your situation) in order for your item to display in the dropdown:

zen_register_admin_page('ceon_uri_mapping_config', 'BOX_CEON_URI_MAPPING',
'FILENAME_CEON_URI_MAPPING_CONFIG', '', 'modules', 'Y', 40);

More discussion in this thread.

You might also need to define the equivalent of FILENAME_CEON_URI_MAPPING_CONFIG if you are creating a new menu template; not certain about that.

[niccol]

Yes you need both the BOX and the FILENAME to be defined somewhere. THe filename may already be defined elsewhere on an existing module. You would need to check that for the specific situation. And the file that is pointed to by the filename needs to exist. That last part may seem obvious but it can be a tiger-trap when building new modules..

[conor]

Hi,

There is also a critical bit of information not addressed at all in this thread: you need to define a constant (in /admin/includes/extra_datafiles/) for this (adjusted to your situation) in order for your item to display in the dropdown

Yes, I noticed this too when I couldn't get a menu item to appear, at the time not having any idea that the language define being missing was the cause of the problem, regardless of the fact that the page had indeed been successfully registered in the admin pages database table.

I have written new admin page registration functionality for all new versions of Ceon's modules (have a load of module updates ready to go and they all include it).

Frustratingly my attempts to put handy sanity checks in for BOTH a missing language define and a filename define were unsuccessful as the language defines aren't loaded by the initsystem until after this registration functionality runs.

The filename sanity check can run though, so at least that's something.

Subsequently, so the user has the easiest time installing the software, all Ceon's new modules that need to register an admin page use a file in admin/includes/functions/extra_functions that autoruns, with content similar to the following:

<?php

/**
 * Ceon Back In Stock Notifications Admin Page Registration.
 *
 * Attempts to create a link to the Ceon Back In Stock Notifications admin utility in the Zen Cart
 * admin menu in Zen Cart 1.5+. After running successfully once, this file deletes itself as it is
 * never needed again!
 * 
 * @package     ceon_back_in_stock_notifications
 * @author      Conor Kerr <zen-cart.back-in-stock-notifications@dev.ceon.net>
 * @copyright   Copyright 2004-2012 Ceon
 * @copyright   Portions Copyright 2008 RubikIntegration team @ RubikIntegration.com
 * @copyright   Portions Copyright 2003-2006 Zen Cart Development Team
 * @copyright   Portions Copyright 2003 osCommerce
 * @link        http://dev.ceon.net/web/zen-cart/back-in-stock-notifications
 * @license     http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
 * @version     $Id: back_in_stock_notifications_admin_page_reg.php 936 2012-02-08 11:13:57Z conor $
 */

if (!defined('IS_ADMIN_FLAG')) {
    die('Illegal Access');
}

// This file should normally only need to be run once, but if the user hasn't installed the software
// properly it may need to be run again. Flag tracks the situation
$can_autodelete = true;

if (function_exists('zen_register_admin_page')) {
    if (!zen_page_key_exists('ceon_bisn')) {
        // Register the Ceon Back In Stock Notifications Admin Utility with the Zen Cart admin
        
        // Quick sanity check in case user hasn't uploaded a necessary file on which this depends
        $error_messages = array();
        
        if (!defined('FILENAME_CEON_BACK_IN_STOCK_NOTIFICATIONS')) {
            $error_messages[] = 'The Back In Stock Notifications filename define is missing.' .
                ' Please check that the file ' . DIR_WS_INCLUDES . 'extra_datafiles/' .
                'back_in_stock_notifications_filenames.php has been uploaded.';
            
            $can_autodelete = false;
            
        }
        
        if (sizeof($error_messages) > 0) {
            // Let the user know that there are problem(s) with the installation
            foreach ($error_messages as $error_message) {
                print '<p style="background: #fcc; border: 1px solid #f00; margin: 1em;' .
                    ' padding: 0.4em;">Error: ' . $error_message . "</p>\n";
            }
        } else {
            // Necessary files are in place so can register the admin page and have the menu item
            // created
            zen_register_admin_page('ceon_bisn', 'BOX_CEON_BACK_IN_STOCK_NOTIFICATIONS',
                'FILENAME_CEON_BACK_IN_STOCK_NOTIFICATIONS', '', 'catalog', 'Y', 40);
        }
    }
}

if ($can_autodelete) {
    // Either the admin utility file has been registered, or it doesn't need to be. Can stop the
    // wasteful process of having this script run again by having it delete itself
    @unlink(DIR_WS_INCLUDES .
        'functions/extra_functions/back_in_stock_notifications_admin_page_reg.php');
}

?>

I hope this example file is of use to other developers.

It automatically deletes itself after registering a page with the admin.. but doesn't do this if the user has forgotten to upload the file containing the page's filename define.

As I said, I had to remove the check for a missing language define, which is a pity, but something's better than nothing! :)

All the best...

Conor
ceon