txp:evaluate functions and custom form templates

Myusername · 2021-06-21 18:25:20

I have the impression that I have read something related to this here, but I can’t find it.

I’m talking about PHP Functions enabled in <txp:evaluate/> and custom form templates, and how these two things make sharing themes difficult. In my opinion, they are part of the theme itself, so somehow these options should be directly connected to the theme. I may be wrong, but watch this.

About functions, if I create a theme with a function through <txp:evaluate/>, and that theme is used in another Textpattern installation, some parts of the theme will break.

Talking about custom form templates, it’s almost the same thing. Assuming I have a form of type HTML, XML, or even JS, whatever. When the theme is installed, these forms will be entered as type “misc”, which will break these forms.

What’s worse is that, for beginning Textpattern users, figuring out what it’s all about might not be easy. Even more so because to find the “problems”, you need to activate the advanced options.

This discourages me a lot to develop and share Textpattern themes, as I can’t find an ideal way to share them. What could I do? A step-by-step tutorial for the novice user? Or else not use these features? Am I missing something here? Is there any way around this?

Last edited by Myusername (2021-06-21 18:28:16)

Bloke · 2021-06-21 20:17:08

Totally on board with this limitation. Prefs is not the place for the form types feature: the Forms panel is. There’s an issue raised to track it, we just need to get it done one day. With regards evaluate, there also needs to be a way to import those when a theme is installed. We’re planning on allowing prefs to be imported in a future implementation of themes, which would permit you to do this.

There is a way around it now, but it’s not pretty. I’ve done it in a theme. It involved writing a bootstrap plugin that’s auto-installed with the theme. Whenever you toggle that plugin on, it can do whatever you want as part of its lifecycle, so in our implementation it read config data that populated prefs and custom content such as sections and categories and article data, etc.

etc · 2021-06-22 08:38:15

The difficulty is to decide what are ‘theme prefs’. Recall that many themes can cohabit: specific section themes, dev ones… Should form types be defined per theme? Then how one defines a site-wise type, say json or xml, for articles export? Same for functions, you might want, say, date be available in any theme.

Myusername wrote #330584:

What’s worse is that, for beginning Textpattern users, figuring out what it’s all about might not be easy. Even more so because to find the “problems”, you need to activate the advanced options.

We can remove the switch and activate advanced options for everyone, but then clients could play with them and break something inadvertently.

Bloke · 2021-06-22 09:37:22

etc wrote #330594:

The difficulty is to decide what are ‘theme prefs’.

Precisely.

If you install a theme and it has, say, a .prefs file, it’s easy to import it on theme installation. We could do that tomorrow. The problem is, it would obliterate any current prefs in the DB.

We have the notion of a pref ‘type’ and define three so far (core, plugin, hidden). Nothing to stop us introducing new types (e.g. theme or theme_plugin and theme_hidden). The only trick then is to find a spot in the txp_prefs DB structure (or introduce a new ‘scope’ column in the table?) that would define whether that pref value was in global scope or theme scope.

On some level, it’d be nice to use the user_name column because that is already indexed and works in our tiered hierarchy of ‘user first, core second’ so all we’d need to do is insert a third tier so it went: ‘theme second, core third’. But that’s not practical because you might still have per-theme per-user prefs. Plus, it’s dirty!

Can’t really see a neat way round it without another column and an extra index. The only thing is, that column would only be used for theme prefs to indicate which theme the pref belongs. Seems a bit of a waste of space.

Alternatively, a linking table: txp_pref_theme. That would also permit a pref to be shared by multiple themes, which has merit.

Open to ideas.

Myusername · 2021-07-14 15:13:42

Talking about custom form types:

From what I’ve noticed, I can’t use the txp:header tag to define a mime type on forms by default. This means that if I want to use the txp:header tag in a form, I first need to create a custom form type, eg ‘HTML’. So in this type of form I can use the txp:header tag to define another type if I want. Right?

So, if I’m right with that, it might not cover all scenarios, but wouldn’t it be nice, by default, for Textpattern to be installed with a mime type of ‘HTML’? That way, any theme that uses forms in html, json, xml or whatever, can take advantage of this type of form together with the tag txp:header.

So if I have for example a form that needs to be in JSON, just put it in ‘HTML’ type with a <txp:header name="Content-Type" value="application/json; charset=utf- 8" />.

And so theme authors can put their forms of various types in ‘HTML’ with their respective mimes types (via txp:header) and all forms will be imported correctly in theme installation. Not ideal, I think, but in the short term it might work, right?

Last edited by Myusername (2021-07-14 15:15:45)

colak · 2021-07-15 06:18:26

You may also need to define it in the prefs.

This is what I have in my preferences>Advanced:

In the one line text field: md5, replace:preg_replace

In the multiline text field:

;[js]
;mediatype="application/javascript"
;title="JavaScript"
[js]
mediatype="application/javascript"
[json]
mediatype="application/json"
[svg]
mediatype="image/svg+xml"
[xml]
mediatype="application/xml"
[txt]
mediatype="text/plain"
[csv]
mediatype="text/csv"
[htm]
mediatype="text/html"
[html]
mediatype="text/html"

In the last field: 1

Myusername · 2021-07-15 13:15:28

colak wrote #331020:

Você também pode precisar defini-lo nas preferências.

Good morning, Colak.

I am aware of this, my comment above was an idea to “fix” the distribution of themes, regarding the types of custom forms.

The first post of this topic explains it better.

etc · 2021-07-16 15:49:19

Myusername wrote #331018:

So, if I’m right with that, it might not cover all scenarios, but wouldn’t it be nice, by default, for Textpattern to be installed with a mime type of ‘HTML’? That way, any theme that uses forms in html, json, xml or whatever, can take advantage of this type of form together with the tag txp:header.

This could work, though I need to check whether txp does not automatically append .html extension to these forms, which would be a problem when accessing their ‘flat’ (disk) versions.

etc · 2021-07-19 12:58:01

Bump. Any drawback from adding ‘external’ html form type to the default setup, anyone?

Textpattern CMS

Textpattern CMS support forum

#1 2021-06-21 18:25:20