search

richjoslin / rivety

An extension of the Zend Framework for easily building websites with logins, permissions and roles, CMS, etc. [WARNING: ABANDONED]
Other
2 stars 1 forks source link

Theme files for controllers not being used. #18

Closed jaybill closed 12 years ago

jaybill commented 12 years ago

My theme files are being used for tpl_common, but for anything in tpl_controllers, it's falling back, even though I've got templates in there. I'm going to add some debug logging statements and try to track down the problem.

jaybill commented 12 years ago

Hoo boy. This started a fairly major refactor of theme pathing. I am not sure what I was thinking when I originally wrote this, but if I could go back in time and punch myself, I would.

jaybill commented 12 years ago

Okay. This is a fairly major change. I have cleaned up all of the pathing code, and with it, some of the paths.

A theme is now structured as follows:

theme structure

The biggest change is that module/controller files are now under the admin or frontend folders. This makes a ton more sense (to me anyway) because a frontend theme is probably going to share stuff between modules and controllers. There's going to be very little sharing within a module between admin and frontend (if any).

Fallback works as follows:

  1. Check the configured theme for the template in question.
  2. Failing that, check the module views folder for said template.

This works the same way in with the core, except that in your theme you just have a module folder for "default". I did this because some day maybe we're going to include another module besides default that would live in "core". Also, someone else might want to extend rivety into a larger application that could also have customization.

I don't believe I made any changes to the views tree within a module, but here's what that looks like, just in case: theme structure

I massively cleaned up the code that handles this. index.php now knows nothing about template files, that's all handled in the abstract and admin controllers. The fallback is still done in the smarty and renderer classes, but it's only derived once.

A side benefit of this is that {$theme_url} will look in the right place for both admin and frontend themes. I still set $admin_theme and such so everything that uses it doesn't completely break.

Fallback for non-template files (js/css/images) doesn't completely work right, but could probably be fixed with a rewrite. I kind of get around this by checking to see if the theme is set to "default" and that there's nothing in the themes folder called "default". If that's true, I set theme_url to core/default/views. (frontend or admin, depending on where you are.) This isn't a perfect solution, but should be serviceable for now.

Also: The filter hook for altering the theme paths is gone for the moment. I put in issue #20 so that doesn't get forgotten about.