Textpattern themes: a plan

hcgtv · 2015-07-16 01:07:43

Stef, did a clean install, cleared my browser cache, looking mo better.

When the install takes me to the languages page, the following is at the top:

array (
  0 => 'name',
  1 => 'page',
  2 => 'css',
  3 => 'description',
  4 => 'in_rss',
  5 => 'on_frontpage',
  6 => 'searchable',
  7 => 'title',
)

As for the tab_skins, why did you go with Skins? Just curious.

I like the details of the skins page, showing Sections, Pages, Style, Forms – but shouldn’t it be Sections, Pages, Forms, Styles to match the drop down?

I was thinking, if we’re going to populate the new Theme with 2 Pages, 1 Style and 6 Forms, shouldn’t they have something in them, like the bare minimum for a site to function. I mean what is a user going to do with a blank plainlinks form?

Which brings me to another idea, why not have the above default set, included as part of the install, that way, no matter what transpires on the backend, the site can still function with defaults. The only reason you’re creating these defaults is because the core has these hard coded in, so the core could display defaults should anything go wrong. I could wipe out any and all pages, forms and styles and the front page would still work.

These defaults would be in the database, but wouldn’t display on the Presentation tabs, these are hard coded, no touchee.

Then the default theme Phil has prepared could be called something other than default, like TXP 4.6 or something, to differentiate the different released Themes, because down the line when 4.7 comes out with a different look, we can package up a TXP 4.7 for those wanting to install it. Take a look at a default TXP 4.5.7 install and compare it to a 4.6-dev install, very different looks.

Looking towards the future, Phil could have different versions of the default theme, single column comes to mind, or whatever Phil may be experimenting with and wants to share with the community.

Will keep testing and playing, if I find anything I’ll post here.

phiw13 · 2015-07-16 02:04:14

Bloke wrote #293296:

Today’s features:

Fixed <skin> oversight (thanks phiw13)

:-) TY.

For your Theme select widget on the pages/Forms/Style tabs, here is an other suggestion: go with the markup pattern used on the Write tab under the ‘Advanced Options’, or the ‘Sort and Display’ twistie (both Master or Admin-layout branch). I think that is closer to Phil’s intent, if I understand correctly (although I must admit that it is not at all clear to me…).

phiw13 · 2015-07-16 02:06:56

hcgtv wrote #293299:

As for the tab_skins, why did you go with Skins? Just curious.

Because that is the identifier used in the code? The language packs then need to be updated with the appropriate string for each language.

gaekwad · 2015-07-16 08:27:04

phiw13 wrote #293303:

Because that is the identifier used in the code? The language packs then need to be updated with the appropriate string for each language.

Are there any additional language strings beyond tab_skins? I’ll grep it properly later, but a quick fix to Textpacks might be doable.

Last edited by gaekwad (2015-07-16 08:27:21)

Bloke · 2015-07-16 11:58:40

Thanks for testing Bert. I noticed that table dump on upgrade actually, couldn’t find the reason, then got sidetracked. I’ll track it down.

Regarding the name ‘skin’, a few reasons:

It is a skin, regardless of what the industry call them :-) The Textpack names will reflect ‘Theme’.
We already have a theme global variable for admin-side themes and I didn’t want anything to clash with some careless use of extract() one day.
It’s a lot shorter to type than public_theme when using it hundreds of times in code, Textpacks, etc.

I think a separate collapsible panel might be order of the day here. Nice and consistent but I’m not sure how that fits with Phil’s vision for the panels so I’ll wait for him to play with it.

The string names are still in flux so it might be worth hanging fire on the translations for the time being so we don’t make extra work for everyone. Plus we don’t know if this will hit 4.6.0 yet or wait for 4.7.0…

hcgtv · 2015-07-16 12:09:12

Bloke wrote #293323:

It is a skin, regardless of what the industry call them :-) The Textpack names will reflect ‘Theme’.

Just curious, it just brings me back to my days working with Nucleus.

Plus we don’t know if this will hit 4.6.0 yet or wait for 4.7.0…

There’s been discussion along those lines, maybe push a 4.6 with whatever bugs and/or small enhancements to the core out, then in 4.7 include Themes and the new admin layout with the tag builder out the way.

At some point though, it would be great to see your Themes branch merged with Phil’s new admin layout, would make creating Themes a whole lot easier.

I’ve been playing with syntax highlighting in the Pages, Forms and Styles tab, trying out different options, I’ll let you know how it goes.

Bloke · 2015-07-16 17:40:09

hcgtv wrote #293299:

shouldn’t it be Sections, Pages, Forms, Styles to match the drop down?

Maybe. The only reason I chose that way round was because Pages and Styles are the two things that go in a Section. Forms are just supporting content. But I take your point about the same order as the menu. I’ll switch it round.

if we’re going to populate the new Theme with 2 Pages, 1 Style and 6 Forms, shouldn’t they have something in them

That’s what I wanted, yes. Sadly Txp had other ideas. The only place these assets are defined is in txpsql.php. I wanted to convert some of the default content into functions in that file so I could include it and use them to populate the defaults. But that file just runs when included, and does all sorts of other stuff like checking if it’s in an installation environment and so forth. So for the time being I made everything blank. If we can figure out how to refactor the setup routine to reuse the default data then that’d be great. Just wanted to make sure the Themes concept worked first before tackling that potentially mammoth endeavour.

why not have the above default set, included as part of the install, that way, no matter what transpires on the backend, the site can still function with defaults.

Yes, I floated that idea with Phil to yank out the initialisation code from the setup routine and have a /themes/default (well, insert sexy theme name here) in the file system that ships with Txp. If you want it, great, you get the default theme and the New Theme routine can use it. If you don’t, just ditch it and replace it with your own theme(s) to have them installed on setup. In fact, if you tweaked the default theme on disk, you could use New Theme to base it on some other setup of your own creation.

But the main problem is what happens if the Forms aren’t created. Thing is, the tags don’t check for the existence of forms before executing so the worst that’ll happen is you’ll get a Form not found error. Though the default Form might cause more problems than that. Never tried removing it to see what happens. Perhaps someone should try and we’ll go from there!

These defaults would be in the database, but wouldn’t display on the Presentation tabs, these are hard coded, no touchee.

Yeah, but people do edit the defaults so if you have these uneditable, hidden assets, people might be like “I’ve emptied my linklist form, why is it still rendering?” Potential confusion.

But there’s a solution somewhere so let’s keep kicking around the ideas and find one.

bici · 2015-07-20 00:45:46

Themes. Templates. this may be of interest

source

Should we be aiming for a TxP Zen Garden?

ruud · 2015-08-07 19:08:20

Bloke wrote #292089:

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.

Pull request sent that make the change from mysql to mysqli.

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

Textpattern CMS

Textpattern CMS support forum

#136 2015-07-16 01:07:43

Re: Textpattern themes: a plan

#137 2015-07-16 02:04:14

Re: Textpattern themes: a plan

Bloke wrote #293296:

#138 2015-07-16 02:06:56

Re: Textpattern themes: a plan

hcgtv wrote #293299:

#139 2015-07-16 08:27:04

Re: Textpattern themes: a plan

phiw13 wrote #293303:

#140 2015-07-16 11:58:40

Re: Textpattern themes: a plan

#141 2015-07-16 12:09:12

Re: Textpattern themes: a plan

Bloke wrote #293323:

#142 2015-07-16 17:40:09

Re: Textpattern themes: a plan

hcgtv wrote #293299:

#143 2015-07-20 00:45:46

Re: Textpattern themes: a plan

#144 2015-08-07 19:08:20

Re: Textpattern themes: a plan

Bloke wrote #292089:

#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

Board footer