Testers needed: flat development (4.7+ only)

etc · 2018-04-12 17:21:11

etc wrote #310939:

Few hours of coding… :-)

does not mean by me! Stef, if you know what to change to avoid the auto .css extension, please do. I can tweak <txp:css /> meanwhile, and we are all set.

Bloke · 2018-04-12 17:42:11

etc wrote #310943:

does not mean by me! Stef, if you know what to change to avoid the auto .css extension, please do.

I’ll look at it tonight.

colak · 2018-04-12 18:40:06

Bloke wrote #310942:

EDIT: We’ve referred to Forms, Styles and Pages collectively as Assets in the documentation (only because that’s what they’re called in the code and I copied it). So we’d need to tweak the docs a tad, nothing major.

What about if it is renamed to Types? It will in the foreseeable future deal with discrete, text mime types, right?

Edit> Yet again json is left out there with its application/json mime type.

Last edited by colak (2018-04-12 18:42:30)

etc · 2018-04-12 19:10:42

If it helps, here is a (not exhaustive) list of possible mimetypes we could support:

[
        'txt'  => 'text/plain',
        'csv'  => 'text/csv',
        'htm'  => 'text/html',
        'html' => 'text/html',
        'css'  => 'text/css',
        'js'   => 'application/javascript',
        'json' => 'application/json',
        'xml'  => 'application/xml',
        // Images
        'svg'  => 'image/svg+xml'
]

Edit: drastically shortened, please complain if something is missing.

colak · 2018-04-12 19:21:13

etc wrote #310949:

If it helps, here is a (not exhaustive) list of possible mimetypes we could support:

whoa! That’s much more than I expected!!!

etc · 2018-04-12 19:35:08

colak wrote #310951:

whoa! That’s much more than I expected!!!

Well, there is probably no reason to store non-editable types in the db, so the list is likely to be shorten. Now a million dollars question: could some of txp users have named his styles with .js, .xml or some other extension? If we enable auto-guessing, this could be a problem.

jakob · 2018-04-12 19:38:08

wow, way to go you two. I think the name “assets” covers a lot of the cases.

Bloke · 2018-04-12 19:57:49

etc wrote #310954:

Well, there is probably no reason to store non-editable types in the db, so the list is likely to be shorten.

Yeah, I’d challenge anyone to edit a .zip or .exe file in the Styles panel!

could some of txp users have named his styles with .js, .xml or some other extension?

Tough. If you rename a file extension in a desktop OS, you lose the ‘shortcut’ ability to double click it and launch the associated app. Or it loads the wrong app.

In Txp, let’s use the same approach: if you use a crappy extension for your stylesheet, you lose the ability to use the native <txp:css /> tag for that asset. If it was done on purpose, you could still use the new tag to output it by overriding the guessed mimetype.

EDIT: the only thing I would say is that if you don’t specify a file extension, should we fall back on assuming .css? In my Stylesheet names I rarely use a name with an extension. Or does this issue only affect file-based assets?

Last edited by Bloke (2018-04-12 19:59:47)

etc · 2018-04-12 20:21:27

My high-level plan would be (once the list is shortened):

all unlisted extensions default to .css on both export and output;
the listed ones are exported with their own extension, without .css;
the old css.php?n=test.js links generated via <txp:css name="test.js" /> still serve text/css mimetype, for backwards compatibility;
to output test.js as application/javascript, link it with some e parameter: css.php?n=test&e=js. Note that this will look for test.js style in the db;
generate the URL above with <txp:css name="test" type="js" /> or simply <txp:css name="test.js" type />.

How’s that?

Bloke · 2018-04-12 20:45:40

etc wrote #310959:

How’s that?

Spiffing. My only reservation is that using the tag <txp:css> to output a URL to something non-CSS is a little wonky. What would this output:

<txp:css name="test" type="js" format="link" media="print" />

Do we ignore the other attributes for non-CSS files?

Also, when using format="link" we assume that the output is going to be a <link> served via css.php? If you specify format="url" you get a raw URL spat back. What if you want your .js to output as a <script> tag? Seems reasonable. What about SVG (assuming you accept the scripting risks)? Should that render <img src="test.svg" /> if you use format="link"?

And what if you want to render the contents verbatim, not as a URL but as the actual content? format="raw" seems useful. Could we accommodate that?

Using the old tag for all this functionality seems fraught with gotchas. Perhaps a new <txp:asset> tag is cleaner to output anything from the Assets — including CSS — as either a URL processed via css.php as you outlined above, or raw output. Either way, people will have to construct their own markup around it. And we then leave <txp:css> to only process CSS (.css) assets.

Textpattern CMS

Textpattern CMS support forum

#41 2018-04-12 17:21:11

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

etc wrote #310939:

#42 2018-04-12 17:42:11

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

etc wrote #310943:

#43 2018-04-12 18:40:06

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

Bloke wrote #310942:

#44 2018-04-12 19:10:42

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

#45 2018-04-12 19:21:13

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

etc wrote #310949:

#46 2018-04-12 19:35:08

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

colak wrote #310951:

#47 2018-04-12 19:38:08

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

#48 2018-04-12 19:57:49

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

etc wrote #310954:

#49 2018-04-12 20:21:27

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

#50 2018-04-12 20:45:40

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

etc wrote #310959:

Board footer