I am attempting to clone the plugin Zenpage, in order to validate and possibly make changes to support an alternate Zenpage theme. When I created the clone in /plugins, it showed up in the admin listing, but it didn't work (no properties/setup page appeared and it hung Zenp).
I changed all the strings "Zenpage" & "zenpage" to an alternate name, so my question is: what else do I need to do in order to create a parallel customized 'MyZenpage' plugin/theme combination?
BTW, I tried installing the ZenSimpleCart plugin, and it didn't work either (same problem: I enabled it, hit Apply, and Zenp hung).
thx.
Zenphoto
Comments
Anyway, when you move something from one folder to another then you have to be sure you have fixed all the references to the files it contains. In the case of Zenpage, there are quite a lot and the interdependencies are everywhere, not just in the plugin.
You never need to clone the plugin. As my colleague said, you can easily add extra functionality without that by either plugins or theme functions.
Clone a theme, if you meant that, is actually easy. Just duplicate the folder and rename it.
The only drawback is that the two themes will share the same theme options internally unless you rename them. But caution the theme option definitions with "zenpage" in the name are not theme ones but actually plugin related ones like the "zenpage_homepage". Not all themes have their own as most like albums per page are general theme options sharead by all themes..
I tried to add a section to the theming tutorial for this:
http://www.zenphoto.org/news/theming-tutorial#duplicating-cloning-a-theme-for-customizations
In the case of the Zenpage plugin, it may blur the line a little between what is part of the core functionality, which is just fine. If I change it, I'm on the hook for keeping it up to date with ongoing releases of Zenp.
However, as a cautionary note, it is exactly this sort of process which has (in my opinion) led to the code-bloat and over complication of the "big name" open-source CMS like Drupal, Joomla (and their various predecessors). I have no magic solution, other than making sure the rules for creating new themes and plugins are very well-defined, and that all the supported themes and plugins adhere strictly.
One suggestion: require themes & plugins to clearly document their dependencies, and require a process in each that checks for conflicts when they are enabled (just as the Captcha plugins do).
Now I'm going to go read Ac's updated tutorial on cloning.
(Thanks Ac!)
PS:As I'm working on this project, I may be able to provide some code that addresses some of these issues, which I will gladly contribute if it is deemed useful by the developers.
Your example is pretty much wrong. You used the Favorites plugin as a basis for a completely different feature, not an extension of what it did.
Always if you want to extend something you should make add-on plugins. Otherwise you are doomed to spending all your time forward fitting fixes and enhancements to the original. You are kidding, right????
We cannot even get someone to write documentation on the basics of Zenphoto--no one ever follows through even if they volunteer in the first place. And then, how do you propose that we "Require" a theme/plugin to do anything? Parse its comments and refuse to load it if it is non-compliant?
Tracking down object-references to 'zenpage' (or 'Zenpage' if that's relevant) elsewhere in the codebase is crucial to being able to do this. I'm wondering if there is a naming protocol already in place, or if not, perhaps one could be adopted, eg: pl_<plugin>,th_<theme>(?)
I'm not intending to be critical here, maybe this stuff already exists or isn't needed. I'm still in the discovery phase working with Zenp, and continue to be amazed at how well designed and thought out it is.
Behind the plugin and Zenphoto itself is an sophisitcated object orientated model that lets you do basically everything you desire. But that might be some work. So in short, there is really no need to "clone" or "duplicate" the plugin with all the trouble.
Maybye you should tell a bit about what you actually trying to do. Maybe we can save you some work...
@Sb: Well, you're already doing that in the case of the Captcha plugins (although I don't know exactly how it's implemented).
One simple approach would be to define reserved plugin names: 'zenp_captcha' & 'zenp_cart' & 'zenp_pages' for example. Require the third-party plugin to declare itself as one of that class, then disable/unlink the previous 'class owner', and link the new one when the admin enables it. The reserved plugin definition could also stipulate minimum required config options, so users could switch between them easily.
@Sb: I agree with you on this one up to a point. On the other hand, in my experience, I've found that authors of large complex open-source systems tend to be unreceptive. While most of them say they are open to outside help, they tend to view outsider suggestions and/or contributions as implicitly critical or finding fault with the work they've already done.
I don't really blame them, it's a natural reaction. One key to solving the problem is to provide a well-defined set of rules for third-party contributions, with particular emphasis on 'classes of extensions' which are bound to step on each others' toes (like Captcha and a Shopping Cart), and naming conventions which allow independent modules to co-exist.
(IMHO)
As for saving me time, you already have -- big time. I've been 'dropping in on' Zenphoto over a period of several years. Your work bringing it to this point is highly appreciated.
1) The reason I suggested you use the favorites plugin as a basis (NOT an extension) is just because of the abstraction it makes of the album concept. But the rest of the plugin--the marking and un marking of favorites, and even perhaps the storage of the content are not what you needed. So again, you based a new feature on the existing plugin, you did not extend nor replace it. Thus there is little probability of future changes to the plugin impacting your version.
2) You mistake a convention for a requirement. There is no "requirement" that the captcha plugins cooperate. Nor would there be a way to enforce such a requirement in the first place. Again, I ask how indeed anyone can require something of third party implementations.
So, you could perhaps make your own captcha plugin. If it did not follow the convention it would be possible for a user to select it and one of the standard ones. Probably would cause issues, though.
Likewise for your ill conceived zenpage plugin clone. How would the real one even know yours existed.
3) We would not know about being un-receptive to outside contributions to the documentation since no one has stepped forward. But your experience in general with open source implementers seems unique. We have now and in the past had people contribute to our project on a short term duration. Some have even stayed longer--I am not the original developer, the project was well established before I even knew of it.
I have also had good experience with other projects where I have contributed features to meet our needs.
But of course developers will evaluate contributions and ideas to insure that they fit the project framework and have a reasonable chance of success. They do have to look out for the good of the project after all.
You are, of course welcome to continue down your path in spite of being advised against the approach. Clearly we cannot require you to take a different approach. We think you will fail. Probably in the short term, but certainly in the long term.
Apropos adapting Favorites to support multiple arbitrary selection sets...
I suppose by providing a much smaller graphic selection button (in effect a checkbox or radio button), two or more of these could co-exist. However, you're still left with the problem of 'printAddToFavorites()' in the various theme page files. It seems to me this suggests an opportunity for a slightly more general 'Selections' plugin, which supports both Favorites, and (as in my case) the concept of a 'static-dynamic-album'. Obviously, that's a subjective issue, and a good example of why the open-source paradigm is so valuable.
Apropos my original question: I was really just trying to ascertain whether I was doing something wrong as far as cloning Zenpage, or, more to the point, was it practical to do so -- fully expecting that the answer would probably be 'no' -- and not wanting to spend any more time on it.
Instead, the answer I got was 'why would you want to do that?', leading to this discussion of 'plugin theory'. I should have been clearer in wording my question. I have no desire to take on the task of maintaining customizations of Zenp core functionality.
Thanks for taking the time to explain these various issues.
Regarding the button. I don't remember how it is styled currently (theme or plugin) but via CSS you certainly can make it smaller by hiding the text and replacing by a background image as an icon for example.
Or some jQuery magic to get a radio button maybe.
I don't want to beat a dead horse here, but the best answer would have been: no we don't have a rigorous set of standards for plugin developers concerning name references and dependency issues. (And) No, modifying zenpage would, in effect, require you to modify zp-core.
It's not a big deal. You and Sb obviously manage the supported plugins so they interoperate successfully, and I have no problem with that. I guess I was just trying to make the point that setting standards that prevent third-party add-ons from conflicting with one another are actually helpful to everyone involved, and don't restrict anyone's freedom.
I'm uncomfortable commenting on this, because it sounds like I'm being critical of what is in my view, one of the best open-source cms' I've ever seen:
-- well conceived object model and coding standards
-- simple, easy to understand file system design
-- clear definition of core vs. customizable folders & files
-- excellent reference manual
-- excellent user-guides
-- a well organized and well managed user forum
-- excellent support by committed knowledgeable developers
Other than Ubuntu, I can't think of any other package I've seen that is so well done in all these key areas. But one of the major deficiencies I see over and over again in the numerous CMS I've tested (which is also critical to the success of any oss package), is failure to define a strict set of rules for packaging third-party content for installation and updating.
I don't see this hampering Zenp in any major way so far, but then I wasn't able to find many third party add-ons either (although maybe I wasn't looking in the right place). The one I actually found and tried to install (the Shopping Cart plugin) installed, but when I tried to enable it, the system hung. I will have to write an installer for my system regardless, so maybe at that point I can contribute something useful to the project.
Thanks again to you and Sb for taking the time to respond on this stuff. I truly do try to answer my own questions, and not impose on your time. I see no major issues going forward, and am enjoying the rapid progress I'm making thanks to this very well conceived codebase and outstanding docs.
http://vh1b.mmax.com/index.php?album=vh1b_top&image=radius_no_radius.jpg
It appears that IE v8 doesn't support a negative margin setting, but in all other respects, the resulting display wasn't too bad. (That said, anyone who's still using a browser that doesn't support the border-radius property deserves what they don't get!)
(Note:this is just a test site with some fun photos, not the main project site.)
Regarding the IE bug. I cannot access the test site. But IE8 is not really current and all IEs below 9 are well known to have serious display issues I personally are tired to care about...;-)
Since I am a Mac user I don't do any tests on IE at all besides some screenshot service tests but with all other proper browsers (I think the theme is that way for some years now and scheduled to be redesigned for 1.4.5 anway)..;-) sbillard however uses Windows. But we generally test with the latest versions possible.
As you surely know there are always some display differences with all browsers. As they say "it's not a bug, it's a feature" we have to live with I fear.
By far the worst documentation & technical support infrastructure I ever used was the so-called 'Knowledge Base' from Microsoft. You could spend hours poring over useless links that matched a key word in your search, and even then, if you found the thing you were looking for, no guaranteed that it was a) accurate, or b) up to date.
It was only after Google came along that a developer had a reasonable means of determining whether something we did was in error, or was it an undocumented 'feature' of Windows. Thankfully, now that we have Virtual computing, we are no longer forced to play in Microsoft's sandbox.