Textpattern themes: a plan

gaekwad · 2015-07-15 11:35:07

Stef, this is brilliant work – well done, and thank you!

Bloke · 2015-07-15 11:56:33

Thanks for trying it out, sorry for any snafus I missed. Very quickly:

Name of theme you’re currently working on. Sure. How about in the Page’s h1? {Theme-name}: Pages
Empty defaults: it is clean. Well, ish. Textpattern forces you to have at least one Page, Style and all the “essential” forms or things will break so that is the minimum requirement. If you assigned the theme to a Section without a Page and Style it would explode. This just protects that convention. Will give it some thought though.
Edit panel squiffiness: cached textpattern.js. Force refresh.
Front page not showing article. Weird. I’ll test that out and try to reproduce, thanks for the report.
<skin> tag. D’oh. Over-zealous find ‘n replace error. ~~Will fix~~ Fixed.

Last edited by Bloke (2015-07-15 21:15:45)

Bloke · 2015-07-16 00:21:58

OK, fixed some of the issues mentioned yesterday. Haven’t added the name of the current skin to the h1 titles yet as the select list might be enough of a visual clue depending on where it is eventually placed.

Today’s features:

Fixed <skin> oversight (thanks phiw13)
Fixed no article content if two themes have the same Form name (thanks hcgtv)
Added Section, Page, Style and Form counts to the Themes panel (details view).
Improved Theme deletion step so it tidies up properly.

If anyone has any mockups or ideas for how synchronisation import/export and notification of which assets are out of date might look, please feel free to share.

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.

Textpattern CMS

Textpattern CMS support forum

#133 2015-07-15 11:35:07

Re: Textpattern themes: a plan

#134 2015-07-15 11:56:33

Re: Textpattern themes: a plan

#135 2015-07-16 00:21:58

Re: Textpattern themes: a plan

#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:

Board footer