Testers needed: flat development (4.7+ only)

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.

etc · 2018-10-20 19:38:34

Vienuolis wrote #314661:

I mean we should avoid dependence from Apache and other non-standard rules, at least in documentation.

I concur, but we seem to do it already.

Vienuolis · 2018-10-21 09:59:26

Being lean, smart, and secure web-publishing loom, Texpattern should respect right web-servers, too. Hiawatha is standards-complied, full-featured, completely documented, light, secure and robust, free open-source HTTP server software, far human-friendlier than NginX, Apache.

Could I submit the third section of that docs with Hiawatha configuration tips?

etc · 2018-10-21 10:49:17

Vienuolis wrote #314670:

Could I submit the third section of that docs with Hiawatha configuration tips?

No doubt you can, that would be ace. Textpattern has a small dev team, so community contributions are essential. I’m not in charge of the docs, but a pull request on this should suffice. Thanks!

gaekwad · 2018-10-21 12:57:21

etc wrote #314660:

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

We have this sort-of covered already with the Nginx boilerplate here — these lines:

  location ^~ /themes/\.txp$ {
    return 403;
  }

Define the thing you want to prevent access to with a regex, then give it the http error code in this case and you’re done.

I will enthusiastically +1 the proposal from Vienuolis to add info about Hiawatha, especially since that will mean I can take a look over winter to tidying up and expanding some of the older documents. I’m very in favour of more ‘how to’ config guides.

gaekwad · 2018-10-21 12:58:34

etc wrote #314671:

No doubt you can, that would be ace. Textpattern has a small dev team, so community contributions are essential. I’m not in charge of the docs, but a pull request on this should suffice. Thanks!

…and if you’re not comfortable with GitHub, I will gladly help with putting it all together.

Vienuolis · 2018-10-21 19:03:12

Thank you both for the kind invitation. I have registered to Github today, and made my first contribution, despite I am not a programmer, though. Will correct to fit the high TxP community standards, thanks for your advice.

Textpattern CMS

Textpattern CMS support forum

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

#151 2018-10-20 19:38:34

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

Vienuolis wrote #314661:

#152 2018-10-21 09:59:26

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

#153 2018-10-21 10:49:17

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

Vienuolis wrote #314670:

#154 2018-10-21 12:57:21

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

etc wrote #314660:

#155 2018-10-21 12:58:34

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

etc wrote #314671:

#156 2018-10-21 19:03:12

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

Board footer