Theme mechanism for TxP 4.0.X

hcgtv · 2007-03-17 00:12:06

After spending a few days, I think I have a working mechanism.

Using mcw_templates, I created a new plugin that uses a root level directory called /templates, this keeps user data away from the /textpattern directory, similar to /files and /images.

Sample Kubrick template layout:

/templates
- ../kubrick
  - ../files
    - nicetitle.js
  - ../forms
    - kubrick_default.article.html
    - kubrick_search_results.article.html
    - kubrick_comments.comment.html
    - kubrick_comment_form.comment.html
    - kubrick_popupcomments.comment.html
    - kubrick_files.file.html
    - kubrick_plainlinks.link.html
  - ../images
    - kubrickheader.jpg
    - kubrickfooter.jpg
  - ../pages
    - kubrick_default.html
  - ../plugins
    - hcg_templates-0.3.txt
  - ../style
    - kubrick_default.css

The /templates directory should contain an .htaccess file to keep prying eyes out of your templates but still allow access to the files and images subdirectories.

This mechanism is working for me locally, just looking for comments in case I missed something.

Last edited by hcgtv (2007-03-17 00:17:05)

mrdale · 2007-03-17 01:27:04

This is really well thought out and needed work. Thank you.

hcgtv · 2007-03-17 08:01:25

Sample Kubrick template layout, part deux:

/templates
- ../kubrick
  - kubrick_default.page.html
  - kubrick_default.article.html
  - kubrick_search_results.article.html
  - kubrick_comments.comment.html
  - kubrick_comment_form.comment.html
  - kubrick_popupcomments.comment.html
  - kubrick_files.file.html
  - kubrick_plainlinks.link.html
  - kubrick_default.style.css
  - …
  - ../files
    - nicetitle.js
  - ../images
    - kubrickheader.jpg
    - kubrickfooter.jpg
  - ../plugins
    - hcg_templates-0.3.txt

mapu · 2007-03-17 09:07:52

I like the first example better. Very good idea, indeed. Especially to implement needed plugins. That way, template packages could be made even more feature filled ;)

But why an extra .htaccess file? Putting an empty index.html into that folder could do the same job.

hcgtv · 2007-03-17 16:52:28

mapu wrote:

I like the first example better. Very good idea, indeed. Especially to implement needed plugins. That way, template packages could be made even more feature filled ;)

In the second example everything resides in one top level folder, I just found it easier while working on templates with an editor, less clicking around. Plugins should be included, this way the user doesn’t have to go hunting them down or running the risk of the plugin version they need getting lost in cyberspace.

But why an extra .htaccess file? Putting an empty index.html into that folder could do the same job.

Template authors would need to remember to add an empty index.html to their folders and the plugin would have to be modified to output index.html when it does it’s export routine. Either or works fine, it depends on how you’d like to approach it.

hakjoon · 2007-03-17 17:55:22

Questions,

Why not put it in /textpattern/ and avoid the whole index.html .htaccess mumbo jumbo?

Why preceed the files with kubrick_ if they are in a Kubrick folder? If we are going to use a prefix shouldn’t all files have them (ie. nicetitles.js)?

Really good work here.

hcgtv · 2007-03-17 22:33:51

hakjoon wrote:

Why not put it in /textpattern/ and avoid the whole index.html .htaccess mumbo jumbo?

The good:

I think of Textpattern as the core, sort of like /bin, templates are user generated additions, either /usr or /opt material. This also makes it easier to do folder comparisons on system upgrades.
background:url(../textpattern/_templates/mistylook/img/icon_feed.gif) no-repeat left center; background:url(/templates/mistylook/images/icon_feed.gif) no-repeat left center; less typing
Hard coding ../textpattern is not future proof, the textpattern directory may be able to move around one day. unless we can have CSS conditionals

The bad:

Needs protection.
mcw_templates forks, where we could instead further one code base. But the code should be opened, like you’re doing with zem event code.

Why preceed the files with kubrick_ if they are in a Kubrick folder?

In the admin section, you will have the opportunity to work on Kubrick while your site still runs fine on the old template. When you’re ready, set the section defaults and away you go.
You may also install different templates to learn from, it’s a great way to get up to speed.

If we are going to use a prefix shouldn’t all files have them (ie. nicetitles.js)?

Cause they’re in the Kubrick folder :)

Really good work here.

Open Source is a scratch your own itch type of thing. I came from Nucleus CMS that has the ability to pick looks from a list, Textpattern on the other hand is more of a CMS, but I miss the templating capabilities.

Over the last three months, I’ve been creating templates locally for my live sites. Thanks to changes in the upcoming 4.0.5, I can pick what Page and Style is the default when I enter that tab. EditArea allows me to work more in the Admin section and less in an external editor. Textpattern, the template machine, who woulda thought ;)

Thanks to everyone for the feedback, cause it either solidifies my thoughts or makes me rethink them, and words of encouragement always give you a second wind.

NeilA · 2007-03-18 05:07:20

Like I said in the other thread Bert – more power to you! ;-)

hakjoon · 2007-03-18 06:06:32

Thanks for the answers Bert. They make a lot of sense to me.

hcgtv · 2007-03-18 08:10:22

Ladies and gents, children of all ages…

The TxP Templates are performing in the center ring.

Last edited by hcgtv (2009-08-29 04:46:45)

marios · 2007-03-18 10:10:31

@bert, thanks for doing this. Your Initiatives highly appreciated :))

The thought, finally to moove the templates Folder out of the textpattern directory makes a lot of sense.

(Easier upgrading options, something that I didn’t consider along the lines at all )

The question now is, how to secure the folder, e.g.: Is mod_rewrite the only option, or are there any other ways to do this ?

regards, marios

Last edited by marios (2007-03-18 10:11:48)

hakjoon · 2007-03-18 15:20:46

How about moving it outside the webroot? Does hcg_templates require a web accessible path? That would make it the most secure.

hcgtv · 2007-03-18 15:51:17

marios, I think mod_rewrite is the cleanest, no need to worry about packaging empty index.html files.

hakjoon, does the Textpattern templating system allow accessing images and javascript files from outside it’s own web root?

hakjoon · 2007-03-18 16:29:36

hcgtv wrote:
hakjoon, does the Textpattern templating system allow accessing images and javascript files from outside it’s own web root?

*slaps forehead* D’oh nevermind.

Last edited by hakjoon (2007-03-18 16:30:40)

hcgtv · 2007-03-19 19:18:05

I had a very productive weekend, finally got some needed rest today.

The Theme Mechanism I propose does work in the light of day, after making sure by going through the core code. I can see where a true templating system would require some more tweaks but that’s up to the dev team, cause there’s just too much hard coded stuff in the core.

Importing Pages, Forms and Styles with a template name as a prefix, the Pages and Style tabs are fine, since we’re talking 2 pages and a style. The Forms tab can get a bit confusing, since there are 8 defaults showing up plus whatever your new template requires. So I ask, can I modify the templates plugin to add a toggle to the Forms tab for turning off the display of the defaults? Any advise on this would be most helpful, cause I’m a newbie on the TxP plugin scene.

Now, I know what I’m doing may seem a bit foreign to regular TxP users. They’ve become accustomed to using one set of default templates on the backend, cause it’s how the core code works. There is no distinction of a template set, like other systems have, it’s more like this is your install, these are your forms, have at it. Then comes the forum posts, I screwed something up, how do I restore the defaults? In my opinion, the defaults should be locked down, want to deviate from the defaults, create a new form and tweak it to your liking.

I still need to do some tidying up and then I’ll begin creating some templates, my goal is to spit out a termplate a week, either from a freely available XHTML template or from a rival system’s most popular downloads. Also, I’d like to take some of the best templates from Textgarden and the other Textpattern template sites and adjust them to work with this new mechanism, if that’s cool.

There are differing ways to tackle a templating system, where the files are stored, how do we name the pages, forms and styles, etc. I’ve seen too many threads on these forums go on infinitum and nothing concrete comes of it, so I’d rather put into practice what I preach and I hope that one day all our differing ways meet up at a true templating system, I’m game.

Last edited by hcgtv (2009-08-29 04:46:15)

Textpattern CMS

Textpattern CMS support forum

#1 2007-03-17 00:12:06

Theme mechanism for TxP 4.0.X

#2 2007-03-17 01:27:04

Re: Theme mechanism for TxP 4.0.X

#3 2007-03-17 08:01:25

Re: Theme mechanism for TxP 4.0.X

#4 2007-03-17 09:07:52

Re: Theme mechanism for TxP 4.0.X

#5 2007-03-17 16:52:28

Re: Theme mechanism for TxP 4.0.X

#6 2007-03-17 17:55:22

Re: Theme mechanism for TxP 4.0.X

#7 2007-03-17 22:33:51

Re: Theme mechanism for TxP 4.0.X

#8 2007-03-18 05:07:20

Re: Theme mechanism for TxP 4.0.X

#9 2007-03-18 06:06:32

Re: Theme mechanism for TxP 4.0.X

#10 2007-03-18 08:10:22

Re: Theme mechanism for TxP 4.0.X

#11 2007-03-18 10:10:31

Re: Theme mechanism for TxP 4.0.X

#12 2007-03-18 15:20:46

Re: Theme mechanism for TxP 4.0.X

#13 2007-03-18 15:51:17

Re: Theme mechanism for TxP 4.0.X

#14 2007-03-18 16:29:36

Re: Theme mechanism for TxP 4.0.X

#15 2007-03-19 19:18:05

Re: Theme mechanism for TxP 4.0.X

Board footer