cbe_if_prod_status - do something according to production status

CeBe · 2012-07-16 20:52:39

A plugin to help you avoid hazardous indexation, especially for not yet live sites.

cbe_if_prod_status on textpattern.org
more info, download and help file

Lets you do things like:

<txp:cbe_if_prod_status value="debug">
    ... what to do or output here ...
<txp:else />
    ... what to do or output otherwise ...
</txp:cbe_if_prod_status>

Plus:

Automatically adds <meta name="robots" content="noindex, nofollow"> if production status is not ‘live’.

How does it sound ?

—

Changelog:

16 Jul 2012 – v0.1 – Initial release
28 Jan 2013 – v0.1.1 – Fix: didn’t output anything if site status == ‘live’
22 Jul 2013 – v0.2 – Neatly rewritten by Jukka Svahn

Last edited by CeBe (2013-07-22 13:57:28)

uli · 2012-07-16 21:39:53

Oh, yummie!

Have your links to page templates and forms revealed, while taking visitors minds off the broken layout with a video of cute kitties in coffee mugs. So-so nice! ;)

^{(Just sneering at myself.)}

I really like your idea!

CeBe · 2012-07-18 15:54:28

This is not precisely my idea. At least, I probably wouldn’t have it by myself if…
Well. To help you understand, let me tell you in english what I wrote in french on my website.
Just for you, happy TXP people !

As the beginning of the help file says, I was given the URL of a website still in development. But, to prevent spiders from indexing, it was given as indices such as : remove the third letter before the end and replace the extension with .fr.cr

Considering all you can leave behind just doing a simple click, this concern is fully legitimate.
Imagine this SEO nightmare: a testing site full of debugging messages, maybe broken at some places, or just a testing site not intended to be publicly released… indexed. And when the real URL comes live either it will come after the test version in search results or, even worse, it simply won’t show. Just because the test version was first.
This could have been avoided by denying indexing with the noindex, nofollow meta. At least from the major search engines (I mean Google and Bing).
That’s what the plugin primarily does: if the site is not in ‘live’ production status, it automatically inserts the proper directive.

Now, I talk to developers.
I guess you make some usage of txp:hide for many purposes. When you put the site online you make sure that all your debugging traces are well hidden, praying you don’t forget one.
If something goes wrong later, it can be handy to very temporarily unhide debugging message and fix that little bug. Fingers crossed that you will not forget to restore your txp:hide. Fingers crossed that no robot comes by that time, adds the SEO. (Don’t ask me how I know)
That would be ideal if a system could automatically switch on and off traces and do something to prevent indexing pages that are being fixed.
Here is the method: instead of txp:hide use

<txp:cbe_if_prod_status value="live">
<txp:else />
    <p>This is a debugging message</p>
</txp:cbe_if_prod_status>

and as soon as you set production statut to ‘testing’ or ‘debug’, messages will appear and indexing will be forbidden.
Don’t forget to set it back to ‘live’ when you’re finished !

Disclaimer: only use this method for small fixes that will take few minutes. If it’s more complicated or if it could take longer, let your live site as is and work on a local development environment. Generally speaking about live websites, do not forget to plug your brain first. This TXP plugin provides only little help and convenience.

maruchan · 2012-07-18 17:17:06

I can see why that is helpful, Claire. Thank you!

hazardous indexation

^good name for a band ;-)

Pat64 · 2012-07-18 18:25:20

Sorry for all, this is a private joke:

;)

CeBe · 2012-07-18 18:57:49

Pat64 a écrit:

;)

Et voilà !

Pat64 · 2012-07-19 14:59:30

Hi Claire :)

Just an idea:

In my case, the old website was made with plain old static HTML pages. Do you think your plugin could manage that (special) kind of context : keep static page display into a TXP environment (with the presence of the index.php file)?

CeBe · 2012-07-19 15:57:57

It took me looong looooong minutes to understand¹ the question, but now it makes sense.
It will probably take looooong hours to find an answer :)

But : there is already an index.php in TXP root folder. Did you mean index.html or index.htm ?

¹ (or not)

Pat64 · 2012-07-19 18:38:06

Ok. I translate:

Une bien étrange idée m’est soudain venue (com’dab’).
Ce plugin serait-il utilisable dans un double environnement : site initial en pages html statiques et une installation de TXP pour la version du site en développement (ces deux environnements sur un même serveur et placé à sa racine) ? Le problème va forcément se poser avec la présence du fichier index.php de TXP ainsi que du fichier .htaccess). Bref, l’intérêt serait de garder l’usage d’un site existant tout en développant sa nouvelle version à l’aide de TXP sans aucune perturbation. Toutefois, je pense que ce ne soit pas possible. Ce serait une belle (et bien intéressante) alternative à rvm_maintenance. Dommage…

Last edited by Pat64 (2012-07-19 18:42:47)

CeBe · 2012-07-19 21:36:50

(La version française suit)

So I understood well.

Technically, I do not think that’s possible. The server fetches (order depends on config) index.html, or index.php, or any file declared as directory index, and if it is not found it will build it by listing the files. When the index is determined it is too late, you can’t go back, even rvm_maintenance can’t do anything about it.

In addition, the idea of using a production environment to develop troubles me. This is dangerous. The risks of explosion with collateral damage are real.
I clearly stated that an intervention in testing or debug mode on a usually live site must not exceed a few minutes. Should it be longer, then deeper the problem is, and you have to reconsider your strategy.
The correct bahviour is: fix/develop in development environment, when you’re done set the site in testing or debug mode, install and check, get back live ASAP.

(I feel like the debate is not over.)

French version :

J’avais donc bien compris.

Techniquement, je ne pense pas que ce soit possible. Le serveur va chercher (l’ordre dépend de la config) index.html, ou index.php, ou tout autre fichier déclaré comme index du répertoire, et s’il ne le trouve pas il va le construire en listant les fichiers présents. Lorsque l’index est déterminé c’est trop tard, on ne peut plus revenir en arrière, même rvm_maintenance n’y pourra rien.

En plus, l’idée d’utiliser un environnement de production pour développer me chiffonne. C’est dangereux. Les risques d’explosion avec dégâts collatéraux sont réels.
J’ai clairement indiqué que travailler en mode debug ou testing sur un site habituellement en production ne doit pas excéder quelques minutes. Si ce devait être plus long, c’est que le problème est plus profond et il faut reconsidérer ta stratégie.
En fait, ce qu’il faut c’est : corriger/développer en environnement de développement, quand c’est fait passer le site en testing ou debug, installer et vérifier, revenir le plus vite possible en live.

(Je sens que le débat n’est pas fini.)

ecklesroad · 2012-12-07 15:32:07

Great plugin in Testing and Debug mode, but it prevents output in Live mode. Switching to Live in 4.5.4 TXP just outputs a blank page when this plugin is enabled.

Gocom · 2012-12-07 16:04:11

ecklesroad wrote:

Great plugin in Testing and Debug mode, but it prevents output in Live mode. Switching to Live in 4.5.4 TXP just outputs a blank page when this plugin is enabled.

It’s likely due to the output buffer modification the plugin does to inject meta tag to the page template. When the site is not in debugging mode, the output buffer callback function returns NULL, which replaces the page contents. It should be returning FALSE to bypass and use the default contents. Other option would be to check the site’s production status before hooking the output buffer handler.

To fix the plugin you could add return false; at the end of cbe_if_prod_start function. Alternatively robots directive can be set with a HTTP header, making template modification unnecessary. As such, you could replace the plugin’s code apart from the tag function with:

if (get_pref('production_status') != 'live')
{
	header('X-Robots-Tag', 'noindex');
}

Last edited by Gocom (2012-12-07 16:06:37)

Textpattern CMS

Textpattern CMS support forum

#1 2012-07-16 20:52:39

cbe_if_prod_status - do something according to production status

#2 2012-07-16 21:39:53

Re: cbe_if_prod_status - do something according to production status

#3 2012-07-18 15:54:28

Re: cbe_if_prod_status - do something according to production status

#4 2012-07-18 17:17:06

Re: cbe_if_prod_status - do something according to production status

#5 2012-07-18 18:25:20

Re: cbe_if_prod_status - do something according to production status

;)

#6 2012-07-18 18:57:49

Re: cbe_if_prod_status - do something according to production status

#7 2012-07-19 14:59:30

Re: cbe_if_prod_status - do something according to production status

#8 2012-07-19 15:57:57

Re: cbe_if_prod_status - do something according to production status

#9 2012-07-19 18:38:06

Re: cbe_if_prod_status - do something according to production status

#10 2012-07-19 21:36:50

Re: cbe_if_prod_status - do something according to production status

#11 2012-12-07 15:32:07

Re: cbe_if_prod_status - do something according to production status

#12 2012-12-07 16:04:11

Re: cbe_if_prod_status - do something according to production status

Board footer