Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Textpattern themes: a plan
Since I use flat files for my templates, I’ve been dealing with .txp file extensions for years, in several editors. I’ve had no trouble at all getting editors to treat .txp files as HTML.
For fellow vim users, this is what your .vimrc file needs:
au BufNewFile,BufRead *.txp set filetype=html
It is important, though, to retain a separate file extension for stylesheets, and .css works fine for that. It’s the default extension for stylesheets handled by cnk_versioning.
Offline
Re: Textpattern themes: a plan
I also use the .txp
file extension without any trouble (in Panic Coda) so as long as that filename can also be used in addition to .html
I’m fine with your suggestion.
Offline
Re: Textpattern themes: a plan
I agree with the discussions around the theme folder structures – they should definitely be isolated form each other.
The whole section issue though, is for me a massive issue.
99.9999% of the sites i have built with Textpattern have been company website selling a product or service. They may have had a blog on the side as a subsection.
This means Textpattern’s context sensitive and natural “lets display everything that exists on the home page chronologically” totally goes out the window. I usually create a Home section a pull a sticky from it into the default page template, thus faking a home page.
If we cannot control creation and naming of sections during theme installation, this definitely for me makes it less useful.
Last edited by CodeWalker (2015-06-22 17:11:14)
Offline
#100 2015-06-22 17:14:36
Re: Textpattern themes: a plan
philwareham wrote #291822:
I also use the
.txp
file extension without any trouble (in Panic Coda) so as long as that filename can also be used in addition to.html
I’m fine with your suggestion.
.txp is fine, nobody really uses that extension.
I can configure Notepad++ to recognize .txp as HTML, and with a special txp:tag syntax file, I could get KomodoIDE to recognize TXP tags within a .txp document. Actually, in hcg_templates I can configure the extensions for Pages, Forms and Styles for export and import. Over the years I’ve experimented with different extensions, and the plugin ships with .page, .form and .css as extensions.
Whenever we have a finalized directory structure, naming scheme and where does this Themes folder reside, I can change my plugin to reflect said changes and start making some Themes. I can call it hcg_themes, keep the old plugin around for historical purposes.
We Love TXP . TXP Themes . TXP Tags . TXP Planet . TXP Make
Offline
#101 2015-06-24 22:07:18
Re: Textpattern themes: a plan
Off topic slightly but because it was mentioned in the thread, the admin-layout-update branch is back on the GitHub project where the pages/forms pages are much wider (without tag builder – which I will find another way of housing).
Offline
#102 2015-06-24 23:17:13
Re: Textpattern themes: a plan
philwareham wrote #292012:
Off topic slightly but because it was mentioned in the thread, the admin-layout-update branch is back on the GitHub project where the pages/forms pages are much wider (without tag builder – which I will find another way of housing).
Installed it, playing around with, mucho like.
Got this error on installation (didn’t get it with either 4.5.7 or 4.6-dev).
Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /home/www/zendstudio/textpattern-alu/textpattern/setup/txpsql.php on line 31
We Love TXP . TXP Themes . TXP Tags . TXP Planet . TXP Make
Offline
#103 2015-06-24 23:22:38
Re: Textpattern themes: a plan
hcgtv wrote #292013:
Deprecated: mysql_connect():
That’s a PHP time bomb waiting to explode. Needs attention in fairly short order.
Unsure why it didn’t bitch in 4.6-dev master, as the setup routines between branches should be the same. Meh, weird. Either way it’s an annoying, but known, fault that requires time and some grunt work to fix.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
#104 2015-06-25 20:52:14
Re: Textpattern themes: a plan
Bloke wrote #292014:
Either way it’s an annoying, but known, fault that requires time and some grunt work to fix.
Anything that can be farmed out to other (helpful) grunts, Steffykins?
Offline
#105 2015-06-25 21:27:03
Re: Textpattern themes: a plan
gaekwad wrote #292084:
Anything that can be farmed out to other (helpful) grunts, Steffykins?
Anyone who knows about PDO, sure, be my guest.
PHP have (rightly) dropped direct MySQL support in favour of the (mostly improved) PDO. It does have glaring omissions — like having to manually create IN
parameter lists, when array support would be far more logical — but on the whole it’s a truckload better.
The PHP team are still supporting mysqli, which could be a quick fix as the functions are broadly similar. So it could be a simple case of going through txplib_db.php
and everywhere you see mysql_*
, replace it with mysqli_*
and hope. Doubt it’s that simple as I bet the parametric nature of the calls will require tweaks to our DB layer, but something along those lines would certainly shut the warnings up and give us time to think. And it’s less invasive than a full PDO switch.
Longer term we probably need to move to PDO in some capacity. That opens up the possibility of supporting other database engines (w00t!), although we would need to weed out the MySQL-specific hacks that are dotted around the place first. We could just swap all mysql_*
calls for PDO-esque calls and refactor all the safe_*()
calls to build parameter lists and it’d work, but you end up reinventing quite a bit as most of the time you want to load your data from the database into objects (we currently load ours into arrays, which are nice and simple, albeit not as well structured as objects). That then becomes an ORM. So the other option is to save all that hassle of writing your own ORM and use an existing framework.
But that comes with baggage. Things like Doctrine or Propel are behemoths that would potentially quadruple the size of Txp, twice over. You don’t have to use the whole library I suppose, but while it gives you a leg up (once you’ve learnt the API, which is no mean achievement) it’s akin to using the Symfony PHP framework. That’s something ridiculous like 38MB of cruft and OO before you’ve written a line of code. Not my idea of fun and lightweight. I did find NotORM which would be my favoured approach as it’s tiny (about 50KB) and does everything Doctrine does (and more) in a far simpler package. But it’s arguably not as well supported as the big boys so I doubt it’ll get adopted.
You sign on the dotted line I guess and makes your choice …
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
#106 2015-06-25 22:41:37
Re: Textpattern themes: a plan
Bloke wrote #292089:
So it could be a simple case of going through
txplib_db.php
and everywhere you seemysql_*
, replace it withmysqli_*
and hope.
It’s not that easy, but making that change is relatively simple. I’ve done it for another project. Took me only 10 minutes, worked at the first try, although it was a smaller project than TXP. The fact that we have safe_
functions in TXP does help a lot.
Doubt it’s that simple as I bet the parametric nature of the calls will require tweaks to our DB layer
I didn’t use any parametric stuff. Queries worked as they did with the mysql_
functions.
What I’m not sure about is how well mixing mysq_ and mysqli_ functions works? I’m thinking about plugins that use mysql_ while TXP would use mysqli_.
I did find NotORM which would be my favoured approach
Offline
#107 2015-06-25 23:02:12
Re: Textpattern themes: a plan
ruud wrote #292094:
It’s not that easy, but making that change is relatively simple.
That’s comforting to know we have a potential short-term solution, thanks for the insight.
I didn’t use any parametric stuff. Queries worked as they did with the
mysql_
functions.
Oh cool, handy to know it works. I’ve never looked at the mysqli_
calls in any detail. In other projects I’ve gone straight from mysql_
to PDO for my sins.
I’m thinking about plugins that use mysql_ while TXP would use mysqli_.
Hmmm. Must admit I (naively?) assumed that Txp plugins will largely use our DB layer, i.e. the safe_
or getRow(s)
calls. Presumably there’s nothing to physically prevent an application using both flavours of call at once, so the only issue would likely be if older plugins try to directly call any mysql_
functions after PHP drop support entirely. That would result in the plugin halting mid-stream, which is not very friendly but there’s probably nothing we can do practically to trap this. Just one of those things we’ll need to communicate so the major crop of plugins can be patched.
Perhaps we should take this discussion off to a new thread and experiment there, as I’ll sleep better knowing that we’re at least using something that is not likely to just disappear any time in the immediate future.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
#108 2015-06-26 07:21:56
Re: Textpattern themes: a plan
MIight be being naive here, but how do other CMSes handle this? Flat file templates are hardly a new concept with no real world usage examples. As far as I know Textpattern is unique (and not in a good way) in using database to store template files. Can other CMS codebases be dissected to help understand how they solve this problem?
It’s the single biggest hurdle to having a useable theme system really. I see it as essential otherwise themes won’t happen.
Regarding security of the themes
directory, you could allow users to change name/location just as they can with files/images directories.
Offline