Currently, ZenMagick supports site wide and theme specific settings/code in a special file named local.php. While this is very handy from a users points of view, it raises a few problems for the application that I have been thinking about.

Due to the nature of PHP, a included source file may contain a mixture of defines, functions, classes and all sorts of global variables. Looking at it from the other side, the included code might use (hopefully) existing classes, methods and global variables.

In order to make all this work it is essential to include local.php globally and not inside a function or class. This, in turn, is bad for the application code as it means there is no way to extract and reuse code to do exctly that.

ZenMagick is an object oriented system and I am starting to wonder if there is an easy way to combine these two worlds. Starting point was the code change to allow programmatical theme switching, which is included in release 0.6.3. If you actually look at the code, you will see ugly cut’n paste in order to accomplish loading the new themes local.php file once a theme switch is detected. Beside the aesthetical question, there is a natural limit to one switch as new code is requried for each new level.

(There is also a logical flaw in the current implementation, as there should be a new root loaded added instead of adding a new path to the current theme loader, but that is another issue)

So, I am pondering to change the way themes can execute custom code. My main concern is that by moving things into a function or class method I will force usage of global for the theme code and make it more difficult for theme code to create global variables…

So, how would it all work?
The plan is to add one or more methods to ZMThemeInfo that can be overwritten by the theme in order to run custom code. The default implementation could be to look for local.php and import it. That way most stuff should still work.

So what about global variables? Well, I think zm_setting could be used, but there is no guarantee that there won’t be collisions with real settings. The solution would be to add similar methods to ZMThemeInfo to manage theme wide settings.

The advantage would be that, once theme handling is properly reimplemented, theme settings would be automatically updated with the new themes values.

ZenMagick would still guarantee that static theme code (meaning all files under extra that start with a lower case letter) is loaded before page execution and classes (uppercase letter) are visible to the loader.

Theme handling and switching would be easier and better scalable and the world be a nicer place

This might all happen as part of the threatened theme handling code rewrite whitout too much impact on already existing sites.