Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#97 2015-06-22 16:15:39

johnstephens
Plugin Author
From: Woodbridge, VA
Registered: 2008-06-01
Posts: 999
Website

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

#98 2015-06-22 16:22:43

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,564
Website GitHub Mastodon

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

#99 2015-06-22 17:08:04

CodeWalker
Member
From: Hampshire, UK
Registered: 2010-01-08
Posts: 110
Website

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

hcgtv
Plugin Author
From: Key Largo, Florida
Registered: 2005-11-29
Posts: 2,722
Website

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.

Offline

#101 2015-06-24 22:07:18

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,564
Website GitHub Mastodon

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

hcgtv
Plugin Author
From: Key Largo, Florida
Registered: 2005-11-29
Posts: 2,722
Website

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

Offline

#103 2015-06-24 23:22:38

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

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

gaekwad
Server grease monkey
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 4,134
GitHub

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

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

ruud
Developer Emeritus
From: a galaxy far far away
Registered: 2006-06-04
Posts: 5,068
Website

Re: Textpattern themes: a plan

Bloke wrote #292089:

So it could be a simple case of going through txplib_db.php and everywhere you see mysql_*, replace it with mysqli_* 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

Avoiding joins is not always faster/better

Offline

#107 2015-06-25 23:02:12

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

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

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,564
Website GitHub Mastodon

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

Board footer

Powered by FluxBB