Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
#1 2013-02-22 15:54:52
- axelintu
- New Member
- Registered: 2012-01-14
- Posts: 5
Theming with static files and the Textpattern Admin Side
I have been using Textpattern for some time now, and I love it but, for a while, I’ve been modifying some files to be able to make the public side work with static files with Steffan Williams’ article on how to use static files for pages and forms (by the way, this work with 4.5.4) and I really like it this way because:
- I find it faster to develop
- I have syntax highlight and
- I can actually switch themes easier by just changing the name of my theme folder from “templates_name_of_my_theme” to “templates” (with some change in settings in the sections tab on the Textpattern admin-side).
I find it easier to do it this way than using a plugin that scares me saying that the plugin messes with my database. Besides no need to do anything in the admin-side to activate it. Just some name changing in the directories.
(by the way if no file for the template or form is found in the directory it uses the normal way)
I would like to know what everybody else thinks, I think It would be cool to have a setting inside Textpattern that let’s you choose to use the static way or the normal way. I think if is as easy as to change some lines in the core files it should be easy to implement something like this, right? or even a plugin that let’s you do this more easily, or change themes like, really really fast.
I know there some more things to consider (like section names and the pages they are linked to) but I think this works in the way textpattern work because every site is anyways made to its own design and function. So the theming would help make this changes from versions of the site or themes of the site.
That’s all I have to say and I hope I’m not in the wrong section of the forum.
Offline
Re: Theming with static files and the Textpattern Admin Side
Hi. I’ve moved this to feature ideas section.
I agree that some options to allow non-database storage of template files is a good idea, and it’s been much requested and debated before. I think Jukka, one of the other core devs, has recently started implementing some new code to make this much easier to achieve – so maybe this’ll happen in the future.
Offline
Re: Theming with static files and the Textpattern Admin Side
I like Jukka’s approach re r5226.
I would support the idea if these templates were also accessible from the web interface. Maybe an approach similar to rvm_css (with a 2 way update) could be implemented.
With the spreading of handheld devices txp’s traditional method is very convenient as it could all be debugged from any internet connected device. I am all for the development of txp but i think that the browser based model should always remain as an option.
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: Theming with static files and the Textpattern Admin Side
This looks really interesting :)
Offline
Re: Theming with static files and the Textpattern Admin Side
There may be some confusion about the recent additions, so let me explain. These changes do not directly affect templates storing method, or how they are handled in the core. These are callbacks that allow plugins to get notified about template reads, and potentially direct the reads to some other location, or do post-processing to the template code.
Like with callbacks in general, these callbacks itself will not be used by core, or change anything else than allow third party code to hook in there. As final note about these changes, keep in mind that being a development branch, nothing is final.
As far as storing templates in filesystem at the core’s end go, it’s possible, but would separate the template code and meta data from each other. Full interaction would still require creating the items from the GUI… unless you want to edit raw data (JSON/XML) files (you can’t just simply to write in those either).
Templates can work without that meta data, it’s not used for constructing pages, but it is used for organizing said templates (forms) in the admin-side interface. These flat file templates would not appear in anywhere. Also deleting said template file would not remove the items/meta from the DB unless there is synchronization involved.
These new changes allow plugins directly read templates from filesystem without any importing or syncing, but if we did that ourselves in core, we had the above problem. Stuff may depend on the templates being in the database, where they wouldn’t be found, unless you do that importing/syncing business (which isn’t the smartest idea).
In any case, this all would be a long process. To be able to even plan any this, we first require that we even had ORM and API for template handling. You quite literally can’t do these additions in the current codebase, not the right way. In other words, the templates have to stay in DB and be simple manage, until there is a codebase to build upon some other system.
Last edited by Gocom (2013-02-24 04:17:42)
Offline