Received via PM on the zen-cart site:
” You have created a fork
Mano -
Your addition to Zen Cart has progressed to the point it is considered a fork and it will no longer be allowed to be supported on the Zen Cart support site. All threads for it will be removed.”
I’ve recently had the request to add a custom config option to an existing plugin. Since I didn’t want to branch the plugin code for this and the options was not of general use I was a bit stuck.
I pondered options like writing custom SQL to clone an existing configuration entry, tracing SQL executed during plugin installation and some even more obscure things.
Then it hit me: the easiest way is, of course, to let the plugin itself do the work. Here are the steps to add custom configuration options to any ZenMagick plugin (of course, you still need to write the code to make use of that!).
- In your theme’s local.php (you might have to create that if it doesn’t exist) add the following lines:
global $zm_the_plugin;
$zm_the_plugin->addConfigValue('My custom option', 'myValue', '75', 'Custom plugin config value');
- Reload any storefront or admin page to execute the code
- Check the database for the new configuration value
- Either remove the code again, or wrap in conditional code, so it will automatically execute again if the plugin ever gets uninstalled/updated etc.
if (!defined(’PLUGIN_REQUEST_ZM_THE_PLUGIN__MYVALUE’)) {
}
You can also create select boxes, etc, just have a look at what other plugins do in their install() method.
The value can be accessed like any other plugin value: $zm_the_plugin->get('myValue');
I’ve been pondering changes to the ZenMagick demo store for a while and I think I might use the upgrade to 0.9.3 to make the homepage look a bit more inviting.
Also, I’ll see to get a few more plugins installed that could be interesting to check out for people - maybe one of the captcha plugins, perhaps a first draft of the facets plugin and also a plugin I just put together to allow to switch between themes
I just added a new site to the list of reference sites. I’ve got a couple more, but I am not sure what the actual status of those stores is.
Some do look pretty much finished, but still show some default content that should probably not be there. If you know of any sites that are not listed, please leave a comment or write to me.
The release notes for ZenMagick 0.9.3 contain a small note saying that zm_cron now comes with a birthday email job.
I think it is worth pondering the fact that someting that typically would be a full zen-cart mode can be done as a single class utilizing an exiting (generic) plugin.
The actual logic of the job to generate birthday emails is about 10 lines of code
Yup, it’s out! However, in the spirit of Sepp Herberger: “After the release is before the release”.
There is already more that I’ve been working on but that didn’t make it into 0.9.3. The tasklist has more details of the general direction, but there is, of course, more than just that.
Also, a couple things are still missing, which I will hopefully find some time to complete soon. The missing bits are:
As usual there will be new plugins to go with ZenMagick 0.9.3. I’ve already blogged about the FirePHP plugin and I might have mentioned that the Who’s Online code moved from core into a plugin (with a slightly changed format).
There will actually also be a new plugin I haven’t written about and that is named zm_form_handler.
It does exactly what the name suggests - it handles form submission and emails the form content to a configurable email address. So this is the ZenMagick equivalent to the generic form handler CGIs that most hosting provider offer.
The advantage is that it does take advantage of all the ZenMagick code, including things like the validation framework, URL mappings, etc.
The simplest possible way of using it would involve the following steps:
- Once the plugin is installed, configure the page name for the new form (the value of main_page)
- Create a new view with the same name that contains a form to submit. If required, set the form id and create your custom validation rules (same as all other form validation is done in ZenMagick)
- Create a notification template (example provided).
- Done!
I’ve finally had the time to download and install ZendOptimizer and ZendGuard.
Both seem to work fine with ZenMagick and in particular in combination with core.php help speeding things up a lot.
I haven’t got any numbers to compare, but relative to running the store without any optimisation make up for perhaps 40% performance gain.
So, this might be time well spend invetigating PHP acceleration, unless your hosting provider does that already for you.
I’ve started tagging old posts, mainly the ones that are series (HowTo, random facts, etc)
I hope this helps to find things a bit more easily
Despite my announcement about the next release I don’t seem to be able to stop myself checking in more and more changes.
Last night I checked in some changes that effectively remove legacy support from plugins. Now, considering that pretty much all plugins (at least the ones I know about) are maintained by myself I figured that would be reasonably safe.
Only exception to the rule (yes, you know there would be on, didn’t you?) is that local.php files now are also can’t use the legacy globals any more. My judgement is that this is a comparatively small price to pay and in any event a lot easier to fix that converting a full theme.
Speaking of releases, I am still determined to release a new version soon - things seem to be pretty stable, I just want to check some performance issues with the code that does the initial load, but it shouldn’t be too far away. To compare my local instalation with real live I might update the demo store a bit ahead to see how that compares with regards to performance…