Page and forms info on the public side in debugging mode

els · 2012-10-20 18:13:27

It would be super handy to be able to just switch on some rendering debugging and have each page and form within wrapped with some template info.

From this thread. I think it would be a useful addition. Don’t know if it’s hard to implement though.

uli · 2012-10-20 20:23:59

Els wrote:

I think it would be a useful addition.

Priceless if immediately linked to the respective pages/forms!

merz1 · 2012-10-22 06:28:35

uli wrote:

Priceless if immediately linked to the respective pages/forms!

Yeeessss +1 :)

For documentation etc.: How hard is it to have some kind of smd_where_used on steroids to insert a txp:hide message on top of every form, page, stylesheet?

uli · 2012-10-22 15:34:30

Markus, I’m curious what exactly you mean. I have a vague idea what it could be, because every once in a while I think that it’d be great to have a kind of switchable “custom field” for forms and pages, where helper links and the necessary diagnostics code could have a place like the one I’ve mentioned. For the purpose I’m thinking of, one field would suffer for covering each and every form and page. I.e. it’d be sufficient to put such code in one form and have it “inserted” (see below) in every page and every form. Do you think of inserting such code at the top of every form/page?

If so, wouldn’t it be even better to not have to think of inserting the code with some “smd_where_used on steroids” but having it generally for every newly created form/page, i.e. not physically inserted but virtually added: additionally executed whenever a form/page is called for the front side, if – and only if – an additional preference checkbox is ticked? (This mustn’t of necessity be when the site is in debugging mode.)

{Slightly edited details to make my thoughts clearer.}

Last edited by uli (2012-10-23 11:13:51)

merz1 · 2012-10-23 10:38:07

uli wrote:

Markus, I’m curious what exactly you mean. (…) Do you think of inserting such code at the top of every form/page?

Well, that’s a clear Yes-and-No. I am still more thinking about the problem :)

The original problem thread is worth taken into account.

I wrote:

smd_where_used on steroids to insert a txp:hide message on top of every form, page, stylesheet

This would be a textual listing or reference of used (stylesheets: where used) forms, plug-ins.

My idea is very rough. But the problem of analyzing an alien TXP site – even without being a TXP site dev – seems pretty obvious.

uli wrote:

If so, wouldn’t it be even better to not have to think of inserting the code (…) but having it (…) not physically inserted but virtually added (…) if – and only if – an additional preference checkbox is ticked? (…)

Yes, but an important part of the solution to be considered:

The metadata necessary to analyze an existing TXP site can be inserted at many places. Important is that metadata must help to get an overview. Metadata can be inserted via HTML comments, txp:hide comments, faked CSS classes or some ASCII data (maybe XML).

(I love the idea of faked CSS classes because many tools like Firefox, ‘web developer’ or firebug can visualize and/or filter such data.)

(The principal goal IMHO:) The metadata output – the condensed structure of a site, page, form – will help to see the TXP skeleton underneath all the HTML markup/output.

Last edited by merz1 (2012-10-23 10:46:14)

uli · 2012-10-24 13:36:08

merz1 wrote:

The original problem thread is worth taken into account.

Yes, that’s the direction I came from. But I also saw you posting two times in the last weeks (both tag amendments? No time for finding them ATM) and guessed you might be thinking similar thoughts like mine there.

merz1 wrote:

analyzing an alien TXP site <snip> The metadata necessary to analyze an existing TXP site can be inserted at many places.

That’s probably why you thought of an smd_where_used approach so you could insert in one go your diagnostics code where you want it to live.
Improving it from site to site, I’m working on a – largely automatic, universally applicable – chunk of code, with quite some if/else logic so portions of code won’t be executed twice without need. That’s why I think that the code could well be executed additionally (perhaps individually for certain forms/pages at users option, but that’s where it needs more of my consideration). I’ll go into more details about what I’m planning when I find the time, maybe tonight.

This would be a textual listing or reference of used (stylesheets: where used) forms, plug-ins. <snip> will help to see the TXP skeleton underneath all the HTML markup/output

The direction you’re thinking here (I know, you’d prefer classes), could that be a tag skeleton with nested branches that sits at the top of the page’s source code, like a mini tag trace?

makss · 2012-10-25 09:38:24

Textpattern already have stack_forms, but need make public access to it.

lib/txplib_misc.php

       function parse_form($name)
        {
                global $txp_current_form;
                static $stack = array();     // <--- need make public access, for sample: global $txp_stack_forms;

Display current stack: echo join('/', $txp_stack_forms);

merz1 · 2012-10-25 16:23:22

merz1 wrote:

This would be a textual listing or reference of used (stylesheets: where used) forms, plug-ins. <snip> will help to see the TXP skeleton underneath all the HTML markup/output

uli wrote:

The direction you’re thinking here (I know, you’d prefer classes), could that be a tag skeleton with nested branches that sits at the top of the page’s source code, like a mini tag trace?

Not sure if I want/need a tag trace. Somehow a tag trace is out of focus because I am trying to describe metadata solutions. If I need a tag trace I use the debug info and use Ctrl-F to hop from point to point :)

A picture: In a flowchart solution a click on a mentioned TXP form would show the TXP code and HTML markup (aka the details). If clients would be willing to pay for documentation I would use flowcharts anyway.

Re. classes: Adding faked CSS classes just popped up because I was using the webdeveloper add-on for Firefox recently a lot. The feature to blend in different page properties when needed is really great.

hixster · 2012-10-26 13:15:45

Hi guys, I am the OP of the original thread. Could someone share with me where is the main .php file that assembles the page and renders it (forms, page template etc..) . I just need add some debug output for our own purposes.

Bloke · 2012-10-26 18:03:30

hixster wrote:

I just need add some debug output for our own purposes.

Can you instead do it by adding:

<txp:php>
// Debug output here
</txp:php>

to your default Page/Form? You could put it in a Form and import it into the relevant templates by adding <txp:output_form form="my_debug_stuff" /> at appropriate locations.

Alternatively, write a simple plugin that hooks into the public site:

register_callback('hix_debug_output', 'textpattern_end');

function hix_debug_output($evt, $stp) {
   global $pretext, $thisarticle;
   dmp($pretext, $thisarticle);
   // Echo other debug stuff here.
}

That’ll run on every page load, irrespective of section, and chuck out whatever you want. The advantage, as Phil Collins might say: No hacket required…

.. I’ll get my coat.

Last edited by Bloke (2012-10-26 18:05:31)

uli · 2012-10-26 18:52:04

Unfortunately even there’s no form name contained in the output.

I’ve been made aware of txplib_misc.php by makss’ post above and there its function fetch_form, but for me and my non-existent PHP knowledge, there are too many backreferences in order to make it output something readable. It more often blanked out the complete window than even murmuring “array” :)

Can the name of the current form be output by a snippet of PHP or does it really need a whole txplib_misc.php?

Last edited by uli (2012-10-26 18:52:52)

makss · 2012-10-30 14:29:48

uli wrote:

Can the name of the current form be output by a snippet of PHP or does it really need a whole txplib_misc.php?

Use inside form:

<txp:php>
	global $txp_current_form;
	echo $txp_current_form;
</txp:php>

Returns the name of the current form.
Nested form now can not be obtained, it is necessary to change txplib_misc.php

Textpattern CMS

Textpattern CMS support forum

#1 2012-10-20 18:13:27

Page and forms info on the public side in debugging mode

#2 2012-10-20 20:23:59

Re: Page and forms info on the public side in debugging mode

#3 2012-10-22 06:28:35

Re: Page and forms info on the public side in debugging mode

#4 2012-10-22 15:34:30

Re: Page and forms info on the public side in debugging mode

#5 2012-10-23 10:38:07

Re: Page and forms info on the public side in debugging mode

#6 2012-10-24 13:36:08

Re: Page and forms info on the public side in debugging mode

#7 2012-10-25 09:38:24

Re: Page and forms info on the public side in debugging mode

#8 2012-10-25 16:23:22

Re: Page and forms info on the public side in debugging mode

#9 2012-10-26 13:15:45

Re: Page and forms info on the public side in debugging mode

#10 2012-10-26 18:03:30

Re: Page and forms info on the public side in debugging mode

#11 2012-10-26 18:52:04

Re: Page and forms info on the public side in debugging mode

#12 2012-10-30 14:29:48

Re: Page and forms info on the public side in debugging mode

Board footer