rvm_maintenance (v0.5)

Pat64 · 2009-07-18 15:37:20

Ok. Thx lot Steve :)

Cheers,

net-carver · 2009-07-18 16:02:44

Patrick

unfortunately, this is not a trivial problem. In my case I had to duplicate enough of the code from the pretext() function to work out if the rss or atom feeds were being asked for in the URL. Recognising the rss & atom url is pretty simple but, unless I’m missing something, your case would need to add another chunk of code to extract the section and then test it against your list of allowed sections. Not pretty but it can be done.

Feel free to email me if you wish to discuss taking this further.

Devs

Perhaps, a core change would help a little here. How about purifying pretext() a little; move all implementation of actions out of the routine…

Specifically, move the two calls in pretext() that handle the rss and atom feeds out, handling the rss/atom url cases after pretext() returns. Perhaps just before the file_download handling code would be a good place.

Now the pretext_end event could be used by Ruud’s plugin — removing the need for my feed mods & trivially handling Patrick’s section exclusion request — as all the pretext variables would be available at that point and no other actions would have yet started (barring any higher priority plugin actions.)

Seems like a cleaner way to do things. However, there must be something I’m missing; usually is.

Last edited by net-carver (2009-07-18 17:05:42)

ruud · 2009-07-18 18:32:03

I’m hooking into the ‘pretext’ callback to make the maintenance script work for rss/atom feeds as well and to correctly initialize the pretext variables.

I was wrong in my earlier response. Try this instead:

function rvm_maintenance()
{
  global $pretext;
  if ($pretext['s'] != 'some-specific-section')
  {
    txp_die('Site maintenance in progress. Please check back later.', 503);
  }
}

Pat64 · 2009-07-19 07:16:09

Ruud

It’s simply great and perfect, as always!

Tkx lot man.
Have a nice day,

net-carver · 2009-07-19 12:28:02

Patrick

Doh! Yes, Ruud is right, that will fix your problem — blind I am.

Ruud

Whilst I agree with the theory of your statement…

I’m hooking into the ‘pretext’ callback to make the maintenance script work for rss/atom feeds as well …

…it doesn’t work for me on a txp 4.0.8 site using a fresh pull of v0.5 of the plugin. Perhaps I’m using it wrongly.

Here’s how I can reproduce the problem…

In browser A, login to Txp on site mysite.com, install the plugin and enable it (it’s the only plugin the site uses.)
In browser B, visit mysite.com/rss or /atom and the feeds are fully readable, regardless of my admin login state in browser A or even if the plugin is enabled or disabled via the admin login in browser A.

Anything messed up in my usage here?

Last edited by net-carver (2009-07-19 12:29:29)

net-carver · 2009-07-19 12:37:50

Ruud

I am sure I am using it right.

On thinking through the sequence of callbacks this plugin uses, it can’t block rss/atom feeds as long as they are served in the pretext() function. Your code does indeed get called at the start of pretext() — adding a callback to have txp die when the pretext_end event is triggered after pretext() returns. The trouble is, pretext() then serves the feed before it returns and the pretext_end event is never triggered as it serves the feeds through an exit() call.

Hence my suggestion of moving all actions out of the pretext() function.

Last edited by net-carver (2009-07-19 12:40:32)

Bloke · 2009-07-27 00:17:16

Heads up: r3258. If it causes any problems, we can back it out before final release of 4.2.0, but it seems to play nicely.

Last edited by Bloke (2009-07-27 00:29:33)

dl33 · 2009-09-16 15:03:48

Using the plugin with txp 4.2 and the admin area set up in a subdomain. When the plugin is activated, the site shows maintenance mode, even if you are logged into the backend. Happens in Firefox and Safari.

ruud · 2009-09-16 22:02:24

dl33, can you give us an example of the domains/urls you use for the public TXP site and the admin area?

dl33 · 2009-09-16 22:17:15

ruud wrote:

dl33, can you give us an example of the domains/urls you use for the public TXP site and the admin area?

The site would run under domain.com, the admin under admin.domain.com. Afraid I can’t give you a live example as I just finished the “maintenance”, so the plugin is no longer activated…

ruud · 2009-09-17 21:17:38

That’s clear enough. It doesn’t work because the cookie required for this login is created under the assumption that the actual website is hosted on admin.domain.com instead of domain.com. Since a cookie for admin.domain.com is never used by the browser when visiting domain.com, the actual website there doesn’t receive it, doesn’t recognize that you’re logged in, so shows the maintenance page.

It’s outside of the control of this plugin, because I’m using the is_logged_in() function that’s built into TXP core, which in turn relies on cookies set in the TXP authentication code. It can’t be fixed, because you cannot serve a cookie for another domain.

jens31 · 2009-11-01 15:50:39

hiii

im having the same problem as dl33.
aint there a chance to tell the plug-in manually, which domains are for front / backend..?
used to use this plug-in everywhere, even in real life ;)

Textpattern CMS

Textpattern CMS support forum

#85 2009-07-18 15:37:20

Re: rvm_maintenance (v0.5)

#86 2009-07-18 16:02:44

Re: rvm_maintenance (v0.5)

#87 2009-07-18 18:32:03

Re: rvm_maintenance (v0.5)

#88 2009-07-19 07:16:09

Re: rvm_maintenance (v0.5)

#89 2009-07-19 12:28:02

Re: rvm_maintenance (v0.5)

#90 2009-07-19 12:37:50

Re: rvm_maintenance (v0.5)

#91 2009-07-27 00:17:16

Re: rvm_maintenance (v0.5)

#92 2009-09-16 15:03:48

Re: rvm_maintenance (v0.5)

#93 2009-09-16 22:02:24

Re: rvm_maintenance (v0.5)

#94 2009-09-16 22:17:15

Re: rvm_maintenance (v0.5)

#95 2009-09-17 21:17:38

Re: rvm_maintenance (v0.5)

#96 2009-11-01 15:50:39

Re: rvm_maintenance (v0.5)

Board footer