Textpattern themes: a plan

Bloke · 2015-06-22 11:58:29

NicolasGraph wrote #291796:

I didn’t know if same form names in different themes could cause problems with the db.

They will today, but if we introduce a new ‘theme’ column and set it up properly, then multiple themes can use the same Form name without issue.

philwareham · 2015-06-22 12:01:19

Or we can not use the database at all?

NicolasGraph · 2015-06-22 12:05:28

Bloke wrote #291797:

They will today, but if we introduce a new ‘theme’ column and set it up properly, then multiple themes can use the same Form name without issue.

Ok, thanks. It is also nice to use the form type as a prefix to sort the forms.

Bloke · 2015-06-22 12:06:28

philwareham wrote #291798:

Or we can not use the database at all?

That too. But see here.

Bloke · 2015-06-22 12:07:38

NicolasGraph wrote #291799:

Ok, thanks. It is also nice to use the form type as a prefix to sort the forms.

Yeah, I like that too. It might be even better if we get to define our own Form types as well :-) But then again, it might not work with themes as that would imply creating Types on the fly when a theme is installed.

hcgtv · 2015-06-22 12:15:56

Bloke wrote #291791:

I was thinking more like:

Themes

abc_theme

Pages

default.txp

about.txp

Forms

article.default.txp

misc.footer.txp

section.layout.txp

Styles

cobalt.txp

Here’s how the default 4.6 theme looks like:

/home/www/textpattern.dev/_templates/default_4.6-dev
├── forms
│   ├── article_listing.article.html
│   ├── comment_form.comment.html
│   ├── comments.comment.html
│   ├── comments_display.comment.html
│   ├── default.article.html
│   ├── files.file.html
│   ├── images.misc.html
│   ├── plainlinks.link.html
│   ├── popup_comments.comment.html
│   ├── search_input.misc.html
│   └── search_results.article.html
├── pages
│   ├── archive.html
│   ├── default.html
│   └── error_default.html
└── style
│ ├── default.css
│ └── ie8.css

3 directories, 16 files

As for the extension, I settled on .html because of the automatic syntax highlighting in editors. You could use .txp and add specific txp:tags to the editor’s available languages if you so desire. Now if Type becomes part of Themes, then the above forms listing would have default.html instead of default.article.html.

I’ve been using Textpattern for many years, there are things in the backend that I’ve never used, like article form preview, or the tag builder, or form type as I’ve pointed out here. As TXP moves forward, if certain legacy features pose a dilemma, a mental roadblock, then my vote is for ctrl-x.

johnstephens · 2015-06-22 16:15:39

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.

philwareham · 2015-06-22 16:22:43

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.

CodeWalker · 2015-06-22 17:08:04

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)

hcgtv · 2015-06-22 17:14:36

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.

philwareham · 2015-06-24 22:07:18

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).

hcgtv · 2015-06-24 23:17:13

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

Bloke · 2015-06-24 23:22:38

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.

gaekwad · 2015-06-25 20:52:14

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?

Bloke · 2015-06-25 21:27:03

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 …

Textpattern CMS support forum

#91 2015-06-22 11:58:29

Re: Textpattern themes: a plan

NicolasGraph wrote #291796:

#92 2015-06-22 12:01:19

Re: Textpattern themes: a plan

#93 2015-06-22 12:05:28

Re: Textpattern themes: a plan

Bloke wrote #291797:

#94 2015-06-22 12:06:28

Re: Textpattern themes: a plan

philwareham wrote #291798:

#95 2015-06-22 12:07:38

Re: Textpattern themes: a plan

NicolasGraph wrote #291799:

#96 2015-06-22 12:15:56

Re: Textpattern themes: a plan

Bloke wrote #291791:

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

Re: Textpattern themes: a plan

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

Re: Textpattern themes: a plan

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

Re: Textpattern themes: a plan

#100 2015-06-22 17:14:36

Re: Textpattern themes: a plan

philwareham wrote #291822:

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

Re: Textpattern themes: a plan

#102 2015-06-24 23:17:13

Re: Textpattern themes: a plan

philwareham wrote #292012:

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

Re: Textpattern themes: a plan

hcgtv wrote #292013:

#104 2015-06-25 20:52:14

Re: Textpattern themes: a plan

Bloke wrote #292014:

#105 2015-06-25 21:27:03

Re: Textpattern themes: a plan

gaekwad wrote #292084:

Board footer