Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Phoenix Admin Hooks


Recommended Posts

When playing about with Phoenix version 1.0.2.0 I created an admin hook (hook_admin_siteWide) to achieve the following on the Categories / Products page (after first checking for $PHP_SELF = ‘categories.php’):
 
1) listen_injectSiteStart
    a) Save $_GET & $_POST data to update new non-core product related table/items later
 
2) listen_injectSiteEnd
    a) action: ‘new_product’
            output new product related table/items and generate jQuery code to display them where relevant on page
    b) action: 'copy_to'
            change the default copy_as - “link” to copy_as - “duplicate”
    c) action: 'new_product_preview'
            change to action 'new_product' (i.e. edit instead of preview)
    d) action = ‘delete_category_confirm’
        action = ‘delete_product_confirm’
            delete a new non-core product related table
    e) action = ‘copy_to_confirm’
             copy new non-core product related table & product items
    f) action = ‘insert_product’
       action = ‘update_product’
            create/update new non-core table/product items using the $_POST data saved in injectSiteStart
    g) Category products list page (isset($_GET['cPath']) && strlen($_GET['cPath']) > 0)
            create hidden table of ids/models, generate jQuery to show id & model on each displayed product line
            copy the Back & New Category/Product buttons displayed at the bottom of the page to also display at the top
 
Although I’ve got absolutely no idea what I’m doing, this seemed to achieve everything I wanted. However, by v1.0.3.0  injectSiteStart has been moved from application_top to template_top, as a result changes 1a/2f no longer work because there is no opportunity to capture the $_POST data (‘update_product’ redirects to the top before the first hook is executed).
 
Using the hooks that are now available in v1.0.3.0 categories.php, I restructured the code for the new calls. The restructure is more elegant and solves the problem above, unfortunately a new problem is introduced – 2b 'copy_to' and 2g ‘Category products list page’ no longer work because output for the page is after the last available hook.
 
Using a mix of the ‘siteWide’ & ‘categories’ hooks would be simple enough to achieve everything but splitting the changes over two different hook groups seems messy and a recipe for future problems/disaster.
 
Questions:
a) Is it possible to have a hook re-introduced into application-top (in order to use the original solution). The Shop side has a hook call in application_top, does the justification for it apply to Admin too?
 
b) Is it possible to have a hook call at the end of categories.php? Perhaps every page that has hooks should have a call at top/bottom? For ‘non-hook’ pages, the hooks in template_top and template_bottom are available (for shop & admin), check against $PHP_SELF to apply to the correct page/script.
 
I could obviously make these changes myself but it goes against “no core changes”. It would be simpler (short term) to insert all the changes into categories.php but it goes against  “no core changes” and, to a degree, it defeats the object of hooks.
 
P.S. A remarkable amount (almost anything?) can be achieved using hooks & javascript/jQuery instead of changing core code. Use the suck it & see approach – base the change on an existing hook and search the net for a javascript/jQuery solution to achieve the changes needed to the page after it is output. Keep playing about until you get what you want. On the Shop side, if you want the ability to turn on/off, use content/header-tag/etc. modules instead of a hook
Link to comment
Share on other sites

2 hours ago, trier said:

b) Is it possible to have a hook call at the end of categories.php? Perhaps every page that has hooks should have a call at top/bottom? For ‘non-hook’ pages, the hooks in template_top and template_bottom are available (for shop & admin), check against $PHP_SELF to apply to the correct page/script.

I'm not following why you need another hook call here.  You already explained how to do it with the template_bottom.php hook.  So why do you still need the new hook at the end of admin/categories.php? 

2 hours ago, trier said:

a) Is it possible to have a hook re-introduced into application-top (in order to use the original solution). The Shop side has a hook call in application_top, does the justification for it apply to Admin too?

Almost certainly this is just something that @burt hasn't done yet.  He might just tell you to send him a pull request.  I think that there is discussion about this in the Phoenix club.  You might try PMing and asking for access.  The criterion is that you must be able to show that you're using Phoenix, preferably on a production site. 

2 hours ago, trier said:

I could obviously make these changes myself but it goes against “no core changes”.

Inserting a hook call isn't quite the same thing.  The ideal would be to go ahead and do that in your store and then ask for it to be added to core via the pull request process.  The hook might get renamed, which would cause you extra work, but it's a lot less work than having to reintegrate your changes into a new version of the file.  And of course most of the actual code would stay the same even after a hook rename. 

Always back up before making changes.

Link to comment
Share on other sites

It's as Matt explains.  

  • show/explain a use case
  • does it make future core things easier
  • is it adoptable by 90% of shopowners

Feel free to send a PR @ github .

To respond to your question; 

so far as I recall there never has been a hook call in admin/includes/application_top.php - did you add this yourself for your own shop?
 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...