I have been looking at the theme api that is currently used in the svn (eg. for a panel:

)

Is this the style we want to keep for the themes or not.  This style keeps our "god" function calling system, "call" for the cms functions "theme" for the theme functions and I think we should add "plugin" for plugin functions (that's a whole other post I think). 

I would like to get some input on what you guys prefer first so we can try and finalise how theming is going to work a bit more.

Well we could use plugin() i guess, it would make it easier for those who are new to developing with the CMS, instead of having to do plugin_name_function name we could add a new argument for the plugin folder. It would actually decrease the processing time because the if/else check to see if its a plugin slows down the CMS a bit.

I would actually like the theme functions moved back into functions/ and use those if that function does not exist in the theme folder. It makes more sense that way as not every theme will need all its stuff changing. However it would have to go inside its own folder in the functions/ folder to make it easy to recognise if its a theme function, maybe add a folder called themes so functions/themes?

I also think all images should have a constant IMAGE as a path, so we can do what paul suggested which was include default images with the CMS and so there is no need for duplicates in each theme. It also means if the user forgets to add that image to the theme it will just use the default one. Now do we include the image by default from the default theme? Or do we put it in the images folder with the news cats and emoticons?

In the images folder would be the easiest IMO

I don't care how it is honestly, just as long as it doesn't change every two days, and the format is somewhat nooby friendly.

I have been thinking about the image path and having themes overwrite the images.   I dont think that would be the best way to go though.  This would only work for the themes that are based off of Default, Energy Blue, and egi pretty much.  If I were to develop a theme that had a completely different layout I would either probably not be able to use those images or I would not want to.  What we could do however is:  Have the theme folder hold the default theme (not in a sub folder), then for every other theme, they can upload their folder into the themes folder.  The new theme can then either, a: specify a new path for the images, b) specify the default path for the images,  c) use no images (mobile phone support)
By using this style we do not have to worry about having a separate image folder which would be more hassle when uploading a theme.

I kind of started rambling my thoughts out but I hope their is somewhat of a point to what I typed.

the "new" -info format has a ['settings']['images'] var, which is (theoretically) used to hold the "default" image page for that theme, that way each layout just recieves $theme_path_images var from code which is constructed per theme request (it can check for the appropriate theme and style from the user & site settings)

The only "issue" atm with this is CSS, and that can be resolved if CSS is supplied via php page/function (seperate from the theme) to replace the correct path.

Why an issue, because the rest of the theme (using -info) is now "path independant", so if you want to "create a new theme based on EGI" you just copy the egi folder, rename it and it works "out of the box" so to speak

ATM, with Whirlpool and XaphireClean, there are some flexible options for images and icons. Whirlpool will automatically supply a list of "foldernames as styles" from its "images" setting. both have one of these !choose options in the dropdown, which allows for a "non theme based" image directory to be used

---

theme functions - atm they use the above (top post) way and those are in the themes folder. I will be "re-integrating" the old theme-functions theme back into the code, for no other reason than the current themes are "messed up", and I know the old ones where tweaked considerably.

the "new" -info format is constructed in such a way as to NOT contain any layout functions when using a standard layout, they just return their $theme['body'] or $theme['panel'], etc, which the code then "wraps" around the appropriate "content" (panel, body, or menu, etc)

So there will be "multiple ways to create themes" and to use them. If the code/functions are seperated from the theme, that makes it easier for designers to "get it right".

Allowing for functions to be held in the theme (like theme-functions) allows for "master designers" to some genuine nifty layouts, but "all in one page". The "3rd" option is a combo of the two, where the theme layout functions are part of the theme (as thay are in the svn right now) and to return "all theme HTML" back to code as a $var, to be inserted by the "correct" theme layout function

I am trying as fast as time allows, to get examples of this into the svn so at least others can see how it works, and then add their "2 cents worth"

I managed to get the entire 2 menus for saphire into one page, using <<<HTML and {$replace_this_var}. This (basically) has no code in it, and is totally readable as HTML output, so editing is done as if each menu where a stand alone HTML page.

Whirlpool is a bit more complex, because of its layout, panels, and plugins, and is taking quite a bit of experimentation, but ATM, there are two ways for this theme to be included, one COMPLETE HTML page per menu item, which is simple (cos its HTML) and fast, but each "page" has repeated code (panels etc).

The other way is to use the "theme layout functions in the theme" which means only the HTML required for each "section" of the page needs to be "defined". This means more "sections" of HTML are defined in the -info, and therefore although each "section" is clearly laid out, the -info may be more complex (for some people)

---

"2 cents worth" can be a LOT sometimes

Hmm ok so we are going to store the image path as $settings['theme_images'] which will include the full path eg default/images.

Paul i dont really like the heradoc style, i prefer to use quotes. I would like to keep theme() and create plugin() instead of using call(plugin_plugin folder_function name).

I would also like to add a settings table similar to the themes  but allows users and not just admins to customize certain things for the plugin if it needs it. Maybe change Admin Preferences to User Preferences? Plugin settings can go in there then.

I would prefer to stick to $head, $title and $body.

Also it is necessary to have the theme functions like star_content etc within the layouts to offer complete customization over the layout.

I would also like to move the theme functions into functions/themes as i stated before and do what Layouts does, see if the file exists in the current theme, if not use the ones in functions/themes. That will cut down a lot of files. Any objections/suggestions?

Yes, no? Need to decide as I want to get the next release out asap

As I have yet to develop using pauls system I can only go by theory.  Pauls system seems to me to be quite robust and allows for a much greater amount of customization within a parameter type file for easy changes.  It seems a bit daunting from just looking at it even though it probably is not that hard to use.

Even with pauls system wont their still need to be a head body and title?  It seems to me that the -info stuff just defines the paths and where everything is located. (I could be completely off though)

Ok added plugin()

Theme functions are now in functions/themes, this removes the need to have multiple function files of the exact same function within every theme.
Moving to Dev Talk

the -info in a couple of the folders should give you an example, the quick search pane is one, and I think the XaphireClean _Admin plugin

I figure [admin], [users] are ok to use, where the admin panel can "limit" [user] according to permissions.

its possible one of the -info has [admin] for admin section, [users] for profile, and [admins] for admin settings in profile

its flexible, and I managed to figure that arrays = dropdowns, and !array = single option. I figure !bang commands could be used to tell eoCMS how to present the info (besides those 2)

in code I would prefer to work with $body etc, so in -info I made the "output" (generally) theme['body']..

if you remember the quick search has an array on ['body'] cos its has 2 different types of output (on table row or 2 table rows). The first one is the default, and the admin/user settings page can store a choice in the db, in this case it would be "qs_body"="2_lines", or some such thing, where "qs_body" and "2_lines" match QuickSearch $panel['body']['2_lines']

I hope that helps.. generally have a look a the -info files in the SVN to get an idea, most each one is different, but some are similar, so make a choice.

I chose names and placement accourding to english output in an HTML page, is such a way that if you were to "dump" the object, you would very quickly understand what is was, like the optional ['author'] or ['creator'] arrays, $key => $value would be totally readable, presentable, and (therefore) understandable (in english)