Textpattern CMS support forum

You are not logged in. Register | Login | Help

#11 2015-06-18 08:35:34

sacripant
Plugin Author
From: Rhône — France
Registered: 2008-06-01
Posts: 476
Website

Re: Textpattern themes: a plan

Bloke wrote #291616:

Ostensibly, a theme in Textpattern is a collection of:

  • Pages
  • Forms
  • Stylesheets
  • Plugins

It depends, that’s your definition
But if you really want to offer specialized and professional theme, your proposal seems too low.

For example if I wish to propose an e-commerce theme with a best UX (front and back). My Theme must contain :

  • Pages
  • Forms
  • CSS
  • JS
  • Plugins
    • Some plugins configurations (bwt_customize configutation, adi_notes with some existing notes, smd_tabber with configured tabs, etc.)
  • Custom fields configurations (actually it’s preferencies)
  • Some site preferencies configurations (use Textile, use comments or not, some publish options, etc.)
  • Specifique Admin theme
  • Some textpack files
  • Some articles already installed

For me, the biggest challenge is how to add plugins configurations and custom fileds configurations. Plugins are différents configurations possibilities : a specifique table in BDD, some specifiques preferencies in prefs table, directely in plugin PHP file. And for custom field configuration, I don’t now, it depends on the work on Txp 4.6.

If you want create a true theme market possibilitie for Textpattern, a theme must be a complete application for specific targets. If not the only themes that could be distributed are simple blogs! And Textpattern will continue to be considered as a old blog system only.

Offline

#12 2015-06-18 08:59:28

colak
Admin
From: Cyprus
Registered: 2004-11-20
Posts: 7,105
Website

Re: Textpattern themes: a plan

Bloke wrote #291631:

Not sure I follow. rvm_privileged is a public plugin, you can use it in any theme you like for restricting access to content.

The privs to control access to the Presentation->Themes panel would take the usual approach of being defined in admin_config.php (and thus overridable via smd_user_manager or bot_privs). Have I missed your point?

Hi Stef, I might be getting all this wrongly and for that I apologise. How I thought the rvm plugin could work is on site design changes. A scenario is that the site designer could work on a new theme for the site which could – during its development time – only be visible to the admins and only when it finishes, the theme could be made available in the front end. It would be a great help if all content could be previewed with this plugin as it would position the plugin in very real situations. It would be great of course if you can think of another way which does away with the rvm plugin and offers full previews to the populated with existing articles themes.


Yiannis
——————————
neme.org | hblack.net | LABS | State Machines | NeMe @ github

Offline

#13 2015-06-18 09:01:44

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,605
Website

Re: Textpattern themes: a plan

NicolasGraph wrote #291628:

Textpack

In what capacity is this theme-related? L10n strings that are used in prefs to control public-side theme usage are going to be handled by smd_prefset. And plugins handle their own strings. So what strings are theme-specific such that they need bundling with a theme?

Images I mentioned in my reply to johnstephens, as I forgot them in the OP.

[Plugins panel] Would it be possible to have the same theme structure than the pages and forms.

Maybe. But there are differences that manifest themselves in UI workflow issues:

  • Pages, Forms and Stylesheets have one copy per theme. That is, any given page can only be assigned to a single theme. From a database viewpoint, it’s a one-to-one mapping. If you select a theme from the dropdown and hit Create new [Page|Form|Stylesheet] then you get a new resource in the currently selected theme. Duplications can be easily catered for too, using the dot notation I mentioned in the OP.
  • Plugins, however, by their very nature have to be shared across themes. Therefore, having a dropdown at the top is fine to show only those plugins that are for the currently selected theme, but you need a way to define which plugins are in use for each theme. Plus a mechanism for allowing one plugin to be associated with more than one theme (and depicting that visually). The many-to-one DB structure behind the scenes isn’t hard to do, it’s how you define things from the UI I’m concerned about. I can’t think of a nice method to assign and display it all without confusion/clutter.
  • Some plugins will be theme independent (workflow plugins such as rah_flat for instance) and these will always be “visible” no matter which theme is currently being worked upon, but should not be packaged with the theme at export time. So they need to be differentiated somehow, visually at least.
  • Unlike with Pages/Forms/Stylesheets which can be ‘switched in and out’ based on selecting a theme, plugins will not be turned on and off (enabled/disabled) when a theme is selected. There are, however, two approaches we can choose from here:
    • (simplest) All plugins still run and are loaded for all themes where their permissions and type apply. Some will be admin-side, some public, some both.
    • (more complicated) Change the load_plugins() function to only load plugins that match the current theme, plus any that are NOT assigned to any theme (i.e. the global ones).

I think prefs are really linked to themes and if Textpattern gives a way to load different themes it should propose a native way to manage their prefs.

OK, I’m not entirely convinced yet (I think this is plugin territory), but let’s explore that anyway. Some prefs, yes. I hadn’t thought of things like comments display modes that do affect the front-end, so that will need thinking about. Good catch. So, firstly, how do you propose this be done in a standard way that make sense for hundreds or thousands of different themes?

I thought to use txp:variables in styles… slows the css loading isn’t it?

Yes. Txp will not parse Stylesheets so you’re out of luck there. smd_styles will permit it, but as you say, it’ll be slower. Re-compilation via SASS when you change a pref is possible if SASS is installed on the server. Changes can either be reflected in the disk-based or DB-based Sheets (or both). That’s likely to be plugin time, not core as we probably won’t be permitted to distribute SASS with Txp! Dunno.

If we have an official path to load themes it would be nice to see rah_flat scanning this path and displaying a select list to switch as you want to make it in the Presentation tab.

That’s up to the plugin, but my guess is that since the directory scheme / zip file structure would be largely based on rah_flat’s mechanism (with just the added “layer” for the theme name), it should be fairly easy to modify the plugin to work seamlessly with themes.


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

#14 2015-06-18 09:24:41

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,605
Website

Re: Textpattern themes: a plan

sacripant wrote #291633:

if you really want to offer specialized and professional theme, your proposal seems too low.

Maybe, maybe not. It’s all about separation of concerns. A lot of what you talk about is admin-related so an admin theme is more appropriate. I think we’re considering two entirely distinct use cases, that have some crossover:

  1. A method to skin existing content with a fresh coat of paint (my OP).
  2. A method to load Txp up from scratch with a spanking new theme, content, admin skin, workflow, yahde yahde (your proposal).

Your idea is great. But it’ll wreak havoc on a site if you already have content installed. How can it add articles to your existing site without potentially destroying your existing stuff? How can it add or alter custom fields? Let’s imagine your clothes website uses custom_1 to hold a Price field and you have 500 articles “for sale”, if you install a theme that has custom_1 defined as colour, and custom_2 is Price, your site is going to break simply by installing the theme. It’s incompatible with the notion of a theme in this case.

I think we need to draw the line on what exactly a theme is, and set the ground rules. That’s what this thread is about and why I started it. The line is blurred of course between admin and public side. Plugins and some pref settings (I hadn’t thought about those, thanks for mentioning it) do play a role. Comment settings, for sure. But things like Textile on/off for articles, the site name, slogan, URL, production status, etc, have nothing whatsoever to do with themes in this context. Custom fields too (currently set up as prefs, but in future they’ll be entirely separate) have no role in what I proposed. They’re content related.

Plugin configuration is a thorny issue. From a workflow perspective you might like to offer adi_matrix or, as you say, smd_tabber tabs. But if you already have those installed and set up for your existing content, installing a public theme shouldn’t trample on all your hard work.

That’s why I’m interested in setting out what we consider a theme to be and, more importantly, what it is not.

If out of all this, a super duper sed_cleaner-style plugin sprouts up which hooks into the initial setup routines of Textpattern and allows you to install and configure a baseline for the type of site you want to make, that’d be brilliant. It’d be like admin theme + public theme + settings + plugins + content all rolled into one. No reason it couldn’t utilise a similar folder structures to that proposed above — an extension of it — and we should definitely consider the possible structure as this takes shape so it can be extended in that manner. But I’d hesitate to call that a “theme”.

Perhaps we need a new name for that kind of thing to differentiate it from the comparatively simplistic skinning exercise I proposed at the top of the thread? Or a new name for Bert’s ‘collection’ proposal outlined in the OP to make it clear that it’s a coat of paint, not an entire eco-system like you propose. I just wouldn’t want the support calls and negative publicity when someone installs a “theme” to try it out and finds it trashes their site by tinkering with content!


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

#15 2015-06-18 09:41:05

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,605
Website

Re: Textpattern themes: a plan

colak wrote #291634:

How I thought the rvm plugin could work is on site design changes.

Gotcha. The concept above uses a dropdown on the Pages/Forms/Stylesheets panels, so does away with the need for rvm_privileged or any theme-based switching logic, which is why I thought maybe <txp:if_theme> wasn’t perhaps necessary.

Let’s take an example. If you set up two themes, Goldfish and Halibut on the Presentation->Themes panel, you set one as the master, public theme. Let’s choose Goldfish, since it’s first and represents your current site.

You’d see those in the select list on each of the existing Presentation panels. Say you go to Presentation->Pages and pick Halibut, your list of Pages changes to those which are assigned to that theme (if any). You create them, edit them, do whatever you like with them. Your existing site still shows Goldfish. But, behind the scenes, the act of choosing Halibut sets a pref or something, just for you. If you go to the Presentation->Forms (or Stylesheets) panel, Halibut will be selected so you can continue to work on that theme until you change your mind. It’d work in a similar way that Txp remembers which twisty panels you’ve opened/closed.

If you then click View site, Txp will first of all see the master Goldfish setting, but before it does anything will check for the pref linked to your account. In this case, it’ll go “Aha, I can see you’re working on the Halibut theme” so it’ll show your site using those Pages/Forms/Stylesheets instead. Thus you can preview it, because you’re logged in.

When ready to go live, you visit Presentation->Themes and change the master theme to Halibut. Everyone will then see that theme. You can of course log in and switch your preview back to Golfish or another theme you started called Shark. When you refresh the public site you see whichever theme you were last working on.

Does that make sense as a workflow? Or is there a better way?


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

#16 2015-06-18 10:28:27

colak
Admin
From: Cyprus
Registered: 2004-11-20
Posts: 7,105
Website

Re: Textpattern themes: a plan

Bloke wrote #291637:

Gotcha. The concept above uses a dropdown on the Pages/Forms/Stylesheets panels, so does away with the need for rvm_privileged or any theme-based switching logic, which is why I thought maybe <txp:if_theme> wasn’t perhaps necessary.

Let’s take an example. If you set up two themes, Goldfish and Halibut on the Presentation->Themes panel, you set one as the master, public theme. Let’s choose Goldfish, since it’s first and represents your current site.

You’d see those in the select list on each of the existing Presentation panels. Say you go to Presentation->Pages and pick Halibut, your list of Pages changes to those which are assigned to that theme (if any). You create them, edit them, do whatever you like with them. Your existing site still shows Goldfish. But, behind the scenes, the act of choosing Halibut sets a pref or something, just for you. If you go to the Presentation->Forms (or Stylesheets) panel, Halibut will be selected so you can continue to work on that theme until you change your mind. It’d work in a similar way that Txp remembers which twisty panels you’ve opened/closed.

If you then click View site, Txp will first of all see the master Goldfish setting, but before it does anything will check for the pref linked to your account. In this case, it’ll go “Aha, I can see you’re working on the Halibut theme” so it’ll show your site using those Pages/Forms/Stylesheets instead. Thus you can preview it, because you’re logged in.

When ready to go live, you visit Presentation->Themes and change the master theme to Halibut. Everyone will then see that theme. You can of course log in and switch your preview back to Golfish or another theme you started called Shark. When you refresh the public site you see whichever theme you were last working on.

Does that make sense as a workflow? Or is there a better way?

Sounds perfect!!!!!!!!!


Yiannis
——————————
neme.org | hblack.net | LABS | State Machines | NeMe @ github

Offline

#17 2015-06-18 10:29:39

philwareham
Core designer
From: Farnham, Surrey, UK
Registered: 2009-06-11
Posts: 3,163
Website

Re: Textpattern themes: a plan

The whole thing would have to be handled as flat files in my opinion. I think the whole database thing for handling forms/pages/css/js is a outdated model of Textpattern that I would not be keen on keeping.

Some sort of supersized version of rah_flat with some directory standards locked in place. I can’t see it working well any other way.

I can provide Bootstrap, Foundation framework-based themes, plus one or two of my own, if that becomes a reality.

Offline

#18 2015-06-18 10:45:25

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,605
Website

Re: Textpattern themes: a plan

philwareham wrote #291639:

The whole thing would have to be handled as flat files in my opinion.

Why? That’s a massive upheaval for limited gain. The same issues regarding prefs and plugins being on/off and not allowed (by PHP) to be duplicated affects the filesystem in exactly the same way as it does the DB. So we might as well support both, since it’s little extra code either way. Additional content such as Bootstrap and Foundation files can still be bundled as assets in the theme for others to tweak / compile in their own filesystems if they wish. The only downside to the DB model is you can’t “compile” stuff without a plugin, if that’s your bag.

Long term, if you’re intent on phasing out the Presentation panels entirely, well, that’s something you’ll have to fight me for :-) Although mildly off-topic, here’s my workflow when I want to tweak a template on my site:

  • Visit Presentation->Pages.
  • Make changes.
  • Save.

And I have the added benefit that adi_form_links helps me jump straight to any associated template files for editing.

Under a filesystem-based approach I’d need to:

  • Open local copy (assuming I have one, if not, download it first).
  • Make changes.
  • Start FTP / file transfer / SSH shell program.
  • Connect / log in.
  • Navigate to correct local and remote directories.
  • Upload file.

For client projects where I have a local mirror for development, flat files make way more sense since it’s their site and changes can be documented in the VCS. But for my own site which doesn’t matter a jot, I’m willing to take the risk of editing it live and for that purpose the admin interface is waaay faster.

Maybe I need to invest in learning some automatic syncing tools so editing any files on my local copy automatically transmits changes when I signal I’m “done”. The only way I can think of is post-commit hooks, which are fine if I cared about versioning my crappy site and jumping through git hoops, but I don’t.


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

#19 2015-06-18 11:04:15

philwareham
Core designer
From: Farnham, Surrey, UK
Registered: 2009-06-11
Posts: 3,163
Website

Re: Textpattern themes: a plan

Bloke wrote #291640:

Why? That’s a massive upheaval for limited gain.

How are we going to store theme CSS, images and JavaScript. In the database? I hope not. WordPress uses flat files for themes still with the option of editing them directly within the control panel – is that not possible for us too?

CSS would also need to have variables injected into it in order to change colours, fonts and suchlike. How would that be handled? Possibly SassPHP or Sass.js I guess could work.

Offline

#20 2015-06-18 11:26:02

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,605
Website

Re: Textpattern themes: a plan

philwareham wrote #291641:

How are we going to store theme CSS, images and JavaScript. In the database?

Images and JS in the filesystem since they don’t have a Txp analog (well, images do, but they’re for content, not presentation). So it’s kind of a hybrid approach. If you clicked import from the Presentation->Themes panel, you’re issuing an admin-side request so the implication is that anything that can be stored in the DB should be. That’s Pages, Forms, Stylesheets and Plugins. Everything else goes in the theme-specific folder, which is in a well-known location and the theme uses anyway.

If, however, you shun the admin-side and unzip the theme in its entirety into the theme-specific folder, the future, theme-aware version of rah_flat would take over and sync everything for you.

WordPress uses flat files for themes still with the option of editing them directly within the control panel – is that not possible for us too?

Absolutely. I misunderstood, sorry. I thought you were advocating removing the admin-side editing process entirely. Moving lock-stock to flat files is more changes than I wanted to make right now with this proposal, but I’d love to get shut of the DB wherever possible, if only for speed reasons. It means backups require both a database and a file system component to be distributed / copied when transferring sites, but you need them both anyway if you have images and files on the site, so a theme folder isn’t that much hardship to add into the mix.

If it turns out that the only way to realise themes is to bypass the DB entirely, then yay! The only reason I wanted to try and do it step by step was because we’d need to change every tag and internal routine that called the DB for template-related content to a different function that read the filesystem. And that’s potentially a lot of work, before we even begin to think about themes on top of that.

CSS would also need to have variables injected into it in order to change colours, fonts and suchlike.

Yeah, that’s a pain. But it’s a pain if editing via the admin-side, whether or not the resulting code is stored in the filesystem or the DB. The only way you can realise that (without a plugin or bundling SASS in core somehow and forcing people to use it) is to edit files outside of Txp in your text editor and compile them, or permit some form of variable injection in the CSS rendering step. Inventive solutions welcome.


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

Board footer

Powered by FluxBB