Textpattern CMS support forum

You are not logged in. Register | Login | Help

#11 2016-10-16 12:55:53

makss
Plugin Author
From: Ukraine
Registered: 2008-10-21
Posts: 355
Website

Re: Output debug info only to logged-in users

It is not always possible to identify the user logged on(txp cookie). For example in the multisite installation is impossible. Therefore it is necessary to consider two options:
  • detect per txp cookie
  • detect per IP

We need to think, maybe it’s all you can do with plugin, so as not to overload txp core.


aks_cron : Cron inside Textpattern | aks_article : extended article_custom tag
aks_cache : cache for TxP | aks_dragdrop : Drag&Drop categories (article, link, image, file)

Offline

#12 2016-10-16 18:28:52

etc
Developer
Registered: 2010-11-11
Posts: 3,106
Website

Re: Output debug info only to logged-in users

makss wrote #302240:

It is not always possible to identify the user logged on(txp cookie). For example in the multisite installation is impossible.

We need to think, maybe it’s all you can do with plugin, so as not to overload txp core.

Valid points. Imo, it should be in core, but if we can not find a universal solution, I will wright myself a tiny mono-site plugin.


etc_[ query | search | pagination | date | tree | cache ]

Offline

#13 2016-10-16 18:55:03

jakob
Moderator
From: Germany
Registered: 2005-01-20
Posts: 3,347
Website

Re: Output debug info only to logged-in users

I like the idea a lot of having the debug infos show when logged in without exposing it to the outside world.

makss wrote #302240:

It is not always possible to identify the user logged on(txp cookie). For example in the multisite installation is impossible.

I have a tentative suggestion for multi-site setups that resolves that problem along with several other anomalies of the multi-site installation process. It’s for v4.6 beta 3 so not quite up-to-date with the latest version but I’ve been trialling it for a while now with a multi-site installation located parallel to the textpattern directory.


TXP Builders – finely-crafted code, design and txp

Offline

#14 2016-10-16 19:38:16

etc
Developer
Registered: 2010-11-11
Posts: 3,106
Website

Re: Output debug info only to logged-in users

jakob wrote #302247:

I have a tentative suggestion for multi-site setups that resolves that problem along with several other anomalies of the multi-site installation process.

Interesting, thank you. Unfortunately, I ignore most of multi-site setup subtleties, but will test.


etc_[ query | search | pagination | date | tree | cache ]

Offline

#15 2016-10-16 20:18:52

makss
Plugin Author
From: Ukraine
Registered: 2008-10-21
Posts: 355
Website

Re: Output debug info only to logged-in users

Another option: Debugging only for me.

In the admin interface display `magic link` after clicking on which set a `magic_debug_cookie`.
Only for this cookie(browser) enable debug mode. The whole site can continue to work normally (‘live’ mode).

I do not want to become attached to the authorization Textpattern, so I suggest creating a separate `magic_debug_cookie`.
For security, can create one-time debugging keys (link/cookie) and to limit the lifetime of the cookie.

Last edited by makss (2016-10-16 20:24:56)


aks_cron : Cron inside Textpattern | aks_article : extended article_custom tag
aks_cache : cache for TxP | aks_dragdrop : Drag&Drop categories (article, link, image, file)

Offline

#16 2016-10-16 23:08:12

maverick
Member
From: Southeastern Michigan, USA
Registered: 2005-01-14
Posts: 960
Website

Re: Output debug info only to logged-in users

Just an fyi/fwiw in case you want to see how one of the “other guys” do it. Symphony CMS drew some inspiration from Textpattern early on in its development. Maybe it can return a spark of inspiration :)

Symphony CMS DevKits Extensions

(edited for grammar)

Last edited by maverick (2016-10-20 14:47:35)

Offline

#17 2016-10-17 04:37:14

colak
Admin
From: Cyprus
Registered: 2004-11-20
Posts: 7,107
Website

Re: Output debug info only to logged-in users

makss wrote #302250:

Another option: Debugging only for me.

+1. Putting the site in debug mode also allows the community to diagnose problems and offer help. As such ‘Debugging only for me.’ should be followed by ‘Debugging visible to everyone’ which is our current way of working.


Yiannis
——————————
neme.org | hblack.net | LABS | State Machines | NeMe @ github

Online

#18 2016-10-17 05:59:30

makss
Plugin Author
From: Ukraine
Registered: 2008-10-21
Posts: 355
Website

Re: Output debug info only to logged-in users

colak wrote #302253:

Putting the site in debug mode also allows the community to diagnose problems and offer help. As such ‘Debugging only for me.’ should be followed by ‘Debugging visible to everyone’ which is our current way of working.

Yes, of course. All modes(live, testing, debug) will work without any changes.
I propose to add a separate `magic_debug_cookie`. If the cookie is set, the output in the debug mode.


aks_cron : Cron inside Textpattern | aks_article : extended article_custom tag
aks_cache : cache for TxP | aks_dragdrop : Drag&Drop categories (article, link, image, file)

Offline

#19 2016-10-17 07:57:54

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,611
Website

Re: Output debug info only to logged-in users

makss wrote #302254:

All modes(live, testing, debug) will work without any changes. I propose to add a separate `magic_debug_cookie`. If the cookie is set, the output in the debug mode.

We’d also need a way to turn it off though, i.e clear the cookie. Otherwise, if you want to return to normal operation in the same session, you’d have to hunt the cookie down and delete it manually. Restarting the browser doesn’t necessarily clear the session, as it remains attached for some time afterwards (30 mins, an hour, browser dependent).

I kinda like the symphony approach because it keeps everything separated, but it’s a bit of a hassle having to install a dev pack first. Also, once installed, if you forget to uninstall/disable it, anybody can add ?debug to the URL and potentially reveal sensitive information.

I like our current system, but having some way to keep the front-end “clean” to visitors while allowing me to dump system info and play with new forms on a live site would be a bonus. Yes it should be done in a staging area, but that’s not always desirable for quick modifications.

Sometimes I temporarily add a new Hidden article called ‘Admin only’ or something and put debug info in there as it’s only available to logged-in users and doesn’t show up front-side. But that’s no good if you’re testing tweaks to Pages/Forms and want to see, for example, whether a plugin is going to work to output some additional info. That’s why I’d like some way to markup my code so I could drop in tags that don’t show up to regular visitors. Like a <txp:debug>...</txp:debug> tag pair, inside which I can drop whatever I want and only I or other privileged users can see it.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#20 2016-10-17 08:58:28

etc
Developer
Registered: 2010-11-11
Posts: 3,106
Website

Re: Output debug info only to logged-in users

Wow, I didn’t mean to open a Pandora box, but all ideas are really interesting. Anyway, whatever core solution we choose, it should work in every setup. I’m currently illiterate in multi-site settings, anyone seeing how to do it please share. Meanwhile, this tiny plugin should work for “traditional” setups:

# Name: etc_private_debug v0.1 
# Type: Public plugin
# 
# Author: 
# URL: 
# Recommended load order: 1

# .....................................................................
# This is a plugin for Textpattern CMS - http://textpattern.com/
# To install: textpattern > admin > plugins
# Paste the following text into the 'Install plugin' box:
# .....................................................................

YToxMTp7czo0OiJuYW1lIjtzOjE3OiJldGNfcHJpdmF0ZV9kZWJ1ZyI7czo2OiJhdXRob3Ii
O3M6MDoiIjtzOjEwOiJhdXRob3JfdXJpIjtzOjA6IiI7czo3OiJ2ZXJzaW9uIjtzOjM6IjAu
MSI7czoxMToiZGVzY3JpcHRpb24iO3M6MDoiIjtzOjQ6ImNvZGUiO3M6MTQ5OiJnbG9iYWwg
JHByb2R1Y3Rpb25fc3RhdHVzOw0KDQppZiAoJHByb2R1Y3Rpb25fc3RhdHVzICE9ICdsaXZl
JyAmJiAhaXNfbG9nZ2VkX2luKCkpIHsNCiAgICAkcHJvZHVjdGlvbl9zdGF0dXMgPSAnbGl2
ZSc7DQogICAgVHJhY2U6OnNldFF1aWV0KHRydWUpOw0KfSI7czo0OiJ0eXBlIjtzOjE6IjAi
O3M6NToib3JkZXIiO3M6MToiMSI7czo1OiJmbGFncyI7czoxOiIwIjtzOjQ6ImhlbHAiO2I6
MDtzOjM6Im1kNSI7czozMjoiYTMxYWNmYmRhOWFhMzVmODdjZjljOTJiNDE2ZTI3ZjMiO30=

If enabled, it should hide (most) debugging info from the outside world. To restore the standard behavior, just disable the plugin.

Last edited by etc (2016-10-17 14:37:28)


etc_[ query | search | pagination | date | tree | cache ]

Offline

Board footer

Powered by FluxBB