Display Textpattern error messages in browser console

sacripant · 2017-09-06 09:21:12

Hello,

actually txp error messages are dispayed in top of html element. I some case (you have a sticky nav to your site), it’s not very convenient and broke your page.
Why not use the browser console for that ? console.log object is now supported by all recent browser (ie11+) and you can easily check if this object exist.

Last edited by sacripant (2017-09-06 09:24:43)

Bloke · 2017-09-06 10:07:47

We have a Textpattern.Console object in ‘textpattern.js’. Perhaps we could/should leverage that at some point.

etc · 2017-09-07 08:38:46

I’m all for making error messages less intrusive, but they should somehow draw admins attention. Not sure the browsers console alone would suffice.

phiw13 · 2017-09-07 12:14:21

etc wrote #306892:

I’m all for making error messages less intrusive, but they should somehow draw admins attention.

+ 1 on that, sometimes those things are little bit in your face (On my local dev machine I’ve added close buttons for those messages with a few lines of JS, so I can nuke them out of the way).

Not sure the browsers console alone would suffice.

Today I was doing some edits to a template on one my sites – using my iPad. I don’t have a browser console in Mobile Safari.

sacripant · 2017-09-07 12:16:08

Thanks to take this this in consideration.
Browser console is the most simpler solution (just wrap existing txp error messages with a console.error() javascript function).

Another solutions / ideas :

admin diagnostics tab. Perhaps improve this tab for templates parser errors ?
admin pages / form tabs : display parsing errors in each forms/pages that have them

etc · 2017-09-07 13:46:13

sacripant wrote #306896:

Another solutions / ideas :

admin diagnostics tab. Perhaps improve this tab for templates parser errors ?

admin pages / form tabs : display parsing errors in each forms/pages that have them

We can not detect every possible public-side error on the admin side (another context). But syntax checking on save is a good idea, thanks, will think about it.

Bloke · 2017-09-07 13:55:25

Yes, a syntax check is a neat idea (at the expense of an error message being displayed somewhere!)

Just one small spanner to be aware of if matching tag start/end: sometimes I split Forms up into 3 parts:

Preamble/header
Content
Postamble/footer

Yes, this can often be done with conditionals such as if_first/last in the ‘content’ Form but sometimes I reuse the content in different situations (e.g. display a bunch of images as a gallery or as a list). By varying which ‘header’ and ‘footer’ I include on the page I can control how the ‘content’ is displayed. Alternatively, I might use the ‘preamble’ Form to inject a different txp:yield variable into the ‘content’ Form.

This might have repercussions if you are syntax checking the ‘preamble’ Form as it might have an opening tag but no corresponding closing tag, since it appears in the ‘postamble’ Form.

It may just be me that does this, but thought I’d mention it in case I’m not alone.

Last edited by Bloke (2017-09-07 13:56:44)

etc · 2017-09-07 13:59:26

Bloke wrote #306898:

This might have repercussions if you are syntax checking the ‘preamble’ Form as it might have an opening tag but no corresponding closing tag, since it appears in the ‘postamble’ Form.

I meant only txp syntax check (via parse()), not HTML. We don’t report HTML errors anyway.

Last edited by etc (2017-09-07 14:04:20)

Bloke · 2017-09-07 14:51:33

etc wrote #306899:

I meant only txp syntax check (via parse()), not HTML. We don’t report HTML errors anyway.

Yeah, and now I’ve confused myself. I swear I’ve done it before where I had an opening txp tag in one Form and the corresponding close tag in another, and I “chained” the Forms (via txp:output_form) to make a complete container tag. Maybe not.

Ignore me then.

etc · 2017-09-07 14:58:41

Weren’t they <txp:variable />? You can do this:

<txp:variable name="open" value="<txp:tag>" />
<txp:variable name="close" value="</txp:tag>" />

<txp:variable name="open" />
...some stuff...
<txp:variable name="close" />

but ...some stuff... will be parsed only on the second pass. This is valid parse-wise anyway, since double-quoted tags attributes are not parsed.

Bloke · 2017-09-07 15:18:37

Yeah, maybe that’s how I did it.

Anyhow, not important. Parsing the Page/Form on save is a great idea. Just got to figure out how best to indicate if there’s a parse error. Does it make sense to use the existing message area, with green if everything’s okay, amber if it saved okay but there was a parse error, and red if there was a form error (like no type or duplicate form name or something)? I don’t think we use WARN for anything else on these panels do we?

etc · 2017-09-07 15:31:25

Bloke wrote #306902:

Does it make sense to use the existing message area, with green if everything’s okay, amber if it saved okay but there was a parse error, and red if there was a form error (like no type or duplicate form name or something)? I don’t think we use WARN for anything else on these panels do we?

Yes, I think, a warning would suffice, since we can not catch processing errors (like invalid attributes) on the admin side, and txp syntax errors are currently only logged, but not displayed. The parser tries to correct them anyway, so they are not critical.

And we still don’t know what to do with public-side errors.

Textpattern CMS

Textpattern CMS support forum

#1 2017-09-06 09:21:12