Textpattern themes: a plan

Bloke · 2018-01-08 23:22:50

For anyone who’s following this thread and not the .com site, there’s now a blog post about Themes. I think it answers most potential questions about what we consider a Theme and what we don’t at this point so if anyone’s at all interested in getting advance lowdown on what to expect, head over and give it a read.

philwareham · 2018-01-09 11:13:12

OK, I’m about to work on providing the Bootstrap 4 framework as a Textpattern theme (which authors can then use as a base for their own designs if they wish). I would want assets (JS, CSS, etc.) to stay out the database in a directory as follows:

/themes/bootstrap_framework/assets/

Since the user can define their own directory name for where themes are stored, how do I approach providing a URL that works? i.e.:

<txp:site_url />my-themes-directory-name/bootstrap_framework/assets/

Where my-themes-directory-name is the value the user has defined for themes.

Bloke · 2018-01-09 11:49:29

That’s a good point. It’s a pref, just like the files directory. At the moment, if you want to make a file download link by hand you need to hard-code the files bit, which is poor given that the admin could have moved them.

Options:

1. Introduce a tag or hijack an existing tag to fetch a link to a named asset of a particular type.

2. Find a safe way to extract prefs values in a tag so they can be used (or tested). smd_if does this and I think it’d be safe to use a core tag for this, since the site designer is in control of which tags are used in the template. Is this something we could look at?

Not sure what would happen if the themes path wasn’t web accessible though. Fail I guess.

fwiw, you can use <txp:page_url type="skin" /> to get the current in-use theme name, but it won’t help you get the full themes path right now.

Last edited by Bloke (2018-01-09 11:51:06)

philwareham · 2018-01-09 12:07:33

Hmmm, this needs to be resolved prior to beta I think, since it’s pretty crucial to the concept of bundled themes. Themes won’t be so useful if we can’t provide JavaScript and images and other assets outside of Textpattern’s database.

Yes we need to be able to find the path of the themes folder – not sure what the best approach is, since the pref for this is currently an absolute path not a relative path.

Bloke · 2018-01-09 12:17:02

philwareham wrote #308579:

this needs to be resolved prior to beta

I agree. It’s not that tough, we just need to pick a method. The only sticking point is…

the pref for this is currently an absolute path not a relative path.

We could alter this so it works like the ‘images’ pref and is therefore relative to docroot. Downside: there’d be no way to hide the template content from the browser (besides the .htaccess rule we’ve put in place for .txp files). Is that a problem do you think?

If themes are more likely than not to have additional assets, we could enforce this as a convention: Themes are public things. When we merge in multi-site and makss (or someone) makes a slight tweak to the way sites are set up, that could give anyone who cares about their template files being exposed an avenue to separate the public-facing assets from the private assets, in the same way that they can change the fact that Textpattern admin files are all in docroot but are forbidden via .htaccess.

philwareham · 2018-01-09 12:38:00

Hi Stef. Yes a relative path for themes directory (akin to images directory pref) would be my vote, and then have some tag or tag attribute to harness that path.

Probably all themes I’d make would have at least some assets within the bundle that need to be public-facing. The default theme (in setup) is the exception to the rule since I implicitly designed that to not have any JavaScript or external assets (apart from the Google font).

Bloke · 2018-01-09 12:54:16

Sounds good. I’ll make Nicolas aware of this and we’ll figure something out with regards getting the content of the relative path pref so it can be used.

michaelkpate · 2018-01-09 15:16:31

philwareham wrote #308582:

Probably all themes I’d make would have at least some assets within the bundle that need to be public-facing. The default theme (in setup) is the exception to the rule since I implicitly designed that to not have any JavaScript or external assets (apart from the Google font).

I’ve been working on doing a Textpattern version of HTML5 Up’s Massively. You can see my current progress.

And it includes an assets folder, which I think is pretty standard in third-party html themes these days.

Bloke wrote #308578:

Not sure what would happen if the themes path wasn’t web accessible though. Fail I guess.

I don’t really see the point of making a .css or .js file inaccessible.

<link rel="stylesheet" href="<txp:site_url />assets/css/main.css" />

<txp:assets type="css" name="main" />

It depends on how far you want to go.

<script src="<txp:site_url />assets/js/jquery.min.js"></script>

<txp:assets type="js" name="jquery" min="y" />

Bloke · 2018-01-09 15:34:10

michaelkpate wrote #308586:

You can see my current progress.

Nice!

it includes an assets folder, which I think is pretty standard

Yeah, I think we’re going to go with an enforced web-accessible themes directory (which you can rename in prefs) but it’ll be a relative path like the images pref. For anyone wanting more security, we can look into being able to split a theme into private/public sections in multi-site setups.

It depends on how far you want to go.

Exactly:

<txp:asset_list type="styles, js">
    <txp:asset format="link" />
</txp:asset_list>

OR how about:

<txp:asset theme="my-other-theme" type="form/article" name="shared-form" />
<txp:asset theme="base-theme" type="js" name="jquery" />

OR:

<txp:site_url /><txp:pref name="skin_dir" />/<txp:page_url type="skin" />/js/my-library.js

:-)

The question is whether we want to permit disk-based access to content that is usually served from the DB (Pages, Forms and Styles in this case). Currently, we can’t output Pages unless they are associated with a Section, whereby they are served automatically. Does it make sense to permit a Page template to be output from disk inside your Theme? Maybe a Page from another Theme?

Since we need to permit Stylesheets to be output as well as other assets like images and javascript, why not Pages and Forms too? Conceptually, Pages are no different to a Form, it’s just that Txp ties them to Sections in the database by convention. Exporting your Theme to disk would open up more functionality, but would it make it more confusing to have two ‘assets’ – one served from the DB and one from disk that may or may not be in sync? <txp:output_form form="article_list" /> (DB) vs <txp:asset type="form" name="article_list" /> (disk).

Not sure. Thoughts welcome from all, as always.

Last edited by Bloke (2018-01-09 15:35:27)

philwareham · 2018-01-09 16:09:51

Bloke wrote #308587:

The question is whether we want to permit disk-based access to content that is usually served from the DB (Pages, Forms and Styles in this case). Currently, we can’t output Pages unless they are associated with a Section, whereby they are served automatically. Does it make sense to permit a Page template to be output from disk inside your Theme? Maybe a Page from another Theme?

Not really IMO. Pages and Forms templates (and Styles if you wish to use them – although I won’t be, in favour of proper file-based CSS) should be stored and then accessed only in the database.

And we have already prevented public access to .txp files in the .htaccess.

Otherwise everything becomes needlessly over-complicated and very breakable.

Bloke · 2018-01-09 16:14:44

philwareham wrote #308588:

Pages and Forms templates (and Styles if you wish to use them – although I won’t be, in favour of proper file-based CSS) should be stored and then accessed only in the database.

That’s fine by me. Nice and simple.

So what’s best? An asset tag (and possible container for looping over assets) of some description to output additional stuff that automatically takes the path into account and spits out valid URLs? Or something that allows you to build the URLs by hand by exposing the prefs and relevant theme settings? Or is there some bit of both we can offer?

philwareham · 2018-01-09 16:30:13

Can we extend the <txp:site_url /> tag with theme directory via an attribute maybe. I don’t want to make it too complex by declaring asset types.

<txp:site_url theme="my-theme-name" />assets/css/main.css

Which would dynamically output both the themes path and the skin name, e.g.

https://example.com/my-theme-folder/my-theme-name/assets/css/main.css

Don’t know – just thinking aloud.

Textpattern CMS

Textpattern CMS support forum

#145 2018-01-08 23:22:50

Re: Textpattern themes: a plan

#146 2018-01-09 11:13:12

Re: Textpattern themes: a plan

#147 2018-01-09 11:49:29

Re: Textpattern themes: a plan

#148 2018-01-09 12:07:33

Re: Textpattern themes: a plan

#149 2018-01-09 12:17:02

Re: Textpattern themes: a plan

philwareham wrote #308579:

#150 2018-01-09 12:38:00

Re: Textpattern themes: a plan

#151 2018-01-09 12:54:16

Re: Textpattern themes: a plan

#152 2018-01-09 15:16:31

Re: Textpattern themes: a plan

philwareham wrote #308582:

Bloke wrote #308578:

#153 2018-01-09 15:34:10

Re: Textpattern themes: a plan

michaelkpate wrote #308586:

#154 2018-01-09 16:09:51

Re: Textpattern themes: a plan

Bloke wrote #308587:

#155 2018-01-09 16:14:44

Re: Textpattern themes: a plan

philwareham wrote #308588:

#156 2018-01-09 16:30:13

Re: Textpattern themes: a plan

Board footer