New Textpattern 4.7.2 pophelps needed

[philwareham]

• [x] 'Enable development theme preview?' Yes/No pref. enable_dev_preview
• [x] 'Advanced options' On/Off pref. advanced_options
• [x] 'Custom form template types' pref field. custom_form_types
• [x] 'PHP functions enabled in txp:evaluate' pref field. txp_evaluate_functions

[bloatware]

One more block to add: txp_evaluate_functions. This is a comma-separated list of PHP function or alias=function items, e.g. md5, replace=str_replace. The items of this list can be used in query attribute of <txp:evaluate />:

<txp:evaluate query="replace('cats', 'dogs', 'I like cats.')" />

function should return a scalar value (not array/object).

[philwareham]

@bloatware @Bloke @petecooper Hi! Anyone care to provide some text for the two missing pophelps listed above? That would complete the en help files for Textpattern 4.7.2.

[petecooper]

@philwareham Without knowing what the code does, I'm at a loss to suggest better versions than those outlined in the OP, honestly. They seem sane enough to me based on what (little) I know.

[bloatware]

Re enable_dev_preview: Users with sufficient privileges (admins, designers) can safely develop and preview a new theme while all the others will still see the old theme (until the new one is deployed). However, privileged users who do not wish to participate in themes development, can disable the development theme preview. They will then be served the current "public" theme, like simple site visitors.

[philwareham]

Thanks @bloatware - just need some guidance on the custom_form_types pop help and we are finished with these for 4.7.2 release. Can you provide a quick summary and I can fill it out?

[bloatware]

@philwareham thanks for taking care of this, I won't have much spare time until Christmas. So, a quick summary:

• In addition to the standard article, file etc form types, site administrators can define custom ones.
• The purpose of custom form types is twofold: easier forms classification and custom assets definition.
• The format of custom_form_types preference is ini, each section corresponding to a form type.
• To define a custom form type, say js, one must append (on a separate line) [js] section.
• A default title can be set via title="Javascript" entry in the corresponding section. If needed, localized titles can be appended as e.g. ru="Скрипт".
• Additionally, a form MIME type can be specified as e.g. mimetype="application/javascript" entry. This turns the forms of this type into custom assets that can be served as such either from db or disk via <txp:output_form /> tag. For example, a form myscript.js of js type can be included as <script /> and served from the disk via <txp:output_form form="myscript.js" format="flat.script" />.
• Only forms with the name extension corresponding to their type (e.g. myscript.js) can be served as flat files. In this case they will not be processed by Textpattern at all and are accessible via their URL.
• If a form needs processing (e.g. contains txp tags), you must serve it from db: <txp:output_form form="myscript.js" format="script" />. In this case you shouldn't (though you can) add the extension to the form name and call it just myscript, to make it inaccessible directly to the outer world.

I hope that's all, but don't hesitate if in doubt.

[philwareham]

All done thanks - closing this one.