Testers needed: flat development (4.7+ only)

jpdupont · 2018-09-09 06:38:47

I put all the 4.7.1 files on the server: same problem.

This makes me think that we should trim the final page output before serving it. I don’t see why anyone would need to start his pages with a space or a linebreak. Edit: done.

But I uploaded the latest version 4.7.2 with the latest Oleg commits: same problem
I also changed the theme, returning to Hive: always the same thing.
Every time I emptied the cache of FFox and reloaded the pages.

phiw13 · 2018-09-09 06:46:01

jpdupont wrote #313937:

I put all the 4.7.1 files on the server: same problem.

But I uploaded the latest version 4.7.2 with the latest Oleg commits: same problem
I also changed the theme, returning to Hive: always the same thing.
Every time I emptied the cache of FFox and reloaded the pages.

Weird. On my various installs, locally or live servers, there is no white-space character before the <!doctype…> on the admin side (or the front-end). Have you tried disabling plugins to see if that changes anything? (and you did check ‘view source’, right?)

jpdupont · 2018-09-09 06:54:45

Yes, I check view source.

I just put the site in work mode and i try now to disable the plugins.

jpdupont · 2018-09-09 07:22:17

That’s it, I found the culprit!

It’s the mck_snippet plugin that I liked to use to store texts that should not be mixed with articles.

Something that is missing in Textpattern, and that could find its place next to other “media”: files, images, links …
I’m going to do without it, and he goes to the trash …

phiw13 · 2018-09-09 07:26:22

jpdupont wrote #313940:

That’s it, I found the culprit!

Great! One step closer to nirvana.

Pat64 · 2018-09-09 09:35:15

etc wrote #313933:

Hi Patrick, no offense intended, that just was the only plugin in Yiannis list that alters the page output, hence an easy suspect, sorry. Also, from what I’ve understood, you need to put it at the very beginning, so an eventual linebreak after it invalidates XML.

This makes me think that we should trim the final page output before serving it. I don’t see why anyone would need to start his pages with a space or a linebreak. Edit: done.

Sure ;)

Thanks lot for the commit: as always you make great things for TXP!

etc · 2018-10-08 15:45:39

Custom (flat) assets management is slowly taking shape in 4.7.2. One can edit and use site components (js, css etc) as forms, defining their mimetype via a pref (currently in Advanced options section). This custom_form_types pref (in ini format) allows also for custom form types definition. Example:

[js]
mimetype="application/javascript"
[shortcode]
*="Short code"
es="Etiqueta corta"

will add js and shortcode to available form types.

As a consequence, easter eggs plugin is not needed anymore for these tasks.

colak · 2018-10-08 17:56:53

etc wrote #314476:

… As a consequence, easter eggs plugin is not needed anymore for these tasks.

? Wonderful news!!! ?

Bloke · 2018-10-09 15:14:42

etc wrote #314476:

[shortcode]
*="Short code"
es="Etiqueta corta"

I know the syntax has changed today but just on an i18n note, are we forcing people to specify language translations in this pref or can they be picked up via `gTxt()` somehow, perhaps via a well-known prefix? Just thinking it’d be easier for plugins/themes to add lang strings than cleanly merge their custom type definitions into the pref (unless there’s a companion API call to do it for them without duplicating existing mime types that may have been defined by hand?)

etc · 2018-10-09 22:06:39

Bloke wrote #314499:

Just thinking it’d be easier for plugins/themes to add lang strings than cleanly merge their custom type definitions into the pref

I totally agree there should be a better way to manage strings, ideas welcome. But why a plugin/theme would add a custom type, which are intended only for easier classification? And custom mimetypes normally do not require translation…

jakob · 2018-10-19 20:45:48

etc wrote #314476:

Custom (flat) assets management is slowly taking shape in 4.7.2. One can edit and use site components (js, css etc) as forms, defining their mimetype via a pref (currently in Advanced options section). This custom_form_types pref (in ini format) allows also for custom form types definition. … As a consequence, easter eggs plugin is not needed anymore for these tasks.

Just trying out 4.7.2 and I like what I see :-)

I’d just like to verify, we (currently) only see these new custom form types if we:

First, add the [formtype] to the list of allowed ‘custom_form_types’ pref in Admin › Preferences › Advanced Options (where necessary with mimetype details), AND
Create a forms/formtype folder in our theme saved on the server and put our form in it, AND
Avoid name clashes with other forms (regardless of form type) AND
Import the theme to the database

But we can choose any name we like (except for already reserved names).

Also, I already see the form types Category and Section. Are they new, or have I just never seen them in the past?

etc · 2018-10-19 23:09:14

jakob wrote #314657:

we (currently) only see these new custom form types if we:

First, add the [formtype] to the list of allowed ‘custom_form_types’ pref in Admin › Preferences › Advanced Options (where necessary with mimetype details), AND

Create a forms/formtype folder in our theme saved on the server and put our form in it, AND

Avoid name clashes with other forms (regardless of form type) AND

Import the theme to the database

But we can choose any name we like (except for already reserved names).

Yes, though the last point is only needed when you develop “flat” forms (on the disk). The second and the third points work as before.

There are some subtleties when you export a MIME-typed form to the disk. Say, you have added js form type with application/javascript MIME type. Then you create two js-type forms: test.js and test_js and export them.

test.js will be saved as is, so you can access it as flat file.
test_js will be saved with .txp extension (test_js.txp) and forbidden for direct access via .htaccess.

Hence, you should save and serve static forms as flat files with extension, and those that contain txp tags without extension, to avoid exposing them to the world. <txp:output_form form="test.js" format="flat.url" /> and <txp:output_form form="test_js" format="url" /> provide their URLs.

Also, I already see the form types Category and Section. Are they new, or have I just never seen them in the past?

I don’t know when they have been introduced, must be 4.6.

Vienuolis · 2018-10-20 06:37:56

forbidden for direct access via .htaccess

Modern HTTP servers, such as NginX, Hiawatha do not need .htaccess — is there some more generic, standards-compliant method?

etc · 2018-10-20 09:37:05

Vienuolis wrote #314659:

Modern HTTP servers, such as NginX, Hiawatha do not need .htaccess — is there some more generic, standards-compliant method?

Servers configuration is not my cup of tea, NginX even less. I guess you’d need to forbid the direct access to .txp files, and Pete @gaekwad should know how :-)

Vienuolis · 2018-10-20 09:47:22

.htaccess rule conversion is not a big problem for me personally. I mean we should avoid dependence from Apache and other non-standard rules, at least in documentation.

Textpattern CMS support forum

#136 2018-09-09 06:38:47

Re: Testers needed: flat development (4.7+ only)

#137 2018-09-09 06:46:01

Re: Testers needed: flat development (4.7+ only)

jpdupont wrote #313937:

#138 2018-09-09 06:54:45

Re: Testers needed: flat development (4.7+ only)

#139 2018-09-09 07:22:17

Re: Testers needed: flat development (4.7+ only)

#140 2018-09-09 07:26:22

Re: Testers needed: flat development (4.7+ only)

jpdupont wrote #313940:

#141 2018-09-09 09:35:15

Re: Testers needed: flat development (4.7+ only)

etc wrote #313933:

#142 2018-10-08 15:45:39

Re: Testers needed: flat development (4.7+ only)

#143 2018-10-08 17:56:53

Re: Testers needed: flat development (4.7+ only)

etc wrote #314476:

#144 2018-10-09 15:14:42

Re: Testers needed: flat development (4.7+ only)

etc wrote #314476:

#145 2018-10-09 22:06:39

Re: Testers needed: flat development (4.7+ only)

Bloke wrote #314499:

#146 2018-10-19 20:45:48

Re: Testers needed: flat development (4.7+ only)

etc wrote #314476:

#147 2018-10-19 23:09:14

Re: Testers needed: flat development (4.7+ only)

jakob wrote #314657:

#148 2018-10-20 06:37:56

Re: Testers needed: flat development (4.7+ only)

#149 2018-10-20 09:37:05

Re: Testers needed: flat development (4.7+ only)

Vienuolis wrote #314659:

#150 2018-10-20 09:47:22

Re: Testers needed: flat development (4.7+ only)

Board footer