rvm_maintenance (v0.5)

renobird · 2009-03-12 13:58:57

I tried that – still no luck.

I’m going to try another install that’s not in a sub-directory

els · 2009-03-12 15:20:00

lonelytraveller, it works fine for me with MLP and 4.0.8. Are you sure you are using the latest version (by graeme)?

lonelytraveller · 2009-03-12 18:18:20

Hi Els, thanks for the fast reply: yes, I’m, using graeme’s latest version: MLP Pack 0.9.11 GP. I’ve installed Textpattern in the root folder, as I always do. I installed rvm_maintenance first (and it seemed to work), then MLP and a couple of other plug-ins. But on another install those same plug-ins do work together with rvm_maintenance. So I thought that buggy MLP could be the reason, ‘cause I’m still having some weird issues: however I just wanted to know if someone else is having the same problem, but if it works for you, then I guess it must be something in my Txp install.

MattH · 2009-06-07 18:52:08

The plugin works perfectly for me with my site homepage and section homepages — that is, I see the splash if I’m not logged in, and the page if I am. However, I cannot see individual article pages, no matter if I am logged in or not. Are there any changes I could make to fix this?

[edit— works in Safari, individual pages don’t show in Firefox]

Last edited by MattH (2009-06-07 19:01:56)

jpdupont · 2009-06-13 06:26:04

The plugin works fine on 2 sites, as expected.
On an other site, same hosting, last 3215 subversion, don’t work.

Here if I activate the plugin, error screen is correctly displayed, but for all people, logged or not logged.

Pat64 · 2009-07-18 08:18:56

Hi Folks.

Is there a way to use rvm_maintenance and give access to public visitors only for a specific section?
I’d trying to use a global $page variable with a conditional test into the plugin without any results.

Help will be much apprecied.
Best regards,

ruud · 2009-07-18 11:59:45

Try adding this before the if construct ($pretext isn’t extracted yet when the plugin triggers).

global $pretext;

and this inside the if construct:

and $pretext['s'] != 'some-specific-section'

Pat64 · 2009-07-18 13:50:00

Ah Ah Ruud!

Nice to read you :))

Nope. I’d tried this without any attempted results:

register_callback('rvm_maintenance_init', 'pretext');

function rvm_maintenance_init()
{
  global $pretext;
  if (txpinterface == 'public' and !gps('txpcleantest') and !is_logged_in() and $pretext['s'] != 'my-specific-section')
  {
    $_GET = $_POST = $_REQUEST = array();
    register_callback('rvm_maintenance', 'pretext_end');
  }
}

function rvm_maintenance()
{
    txp_die('Site maintenance in progress. Please check back later.', 503);
}

Do I made an error?
Cheers,

net-carver · 2009-07-18 15:24:54

Patrick

Unfortunately it’s not as simple as that because the $pretext variables aren’t initialised at the time the function you altered is called.

I had something similar come up with this plugin recently as it wasn’t blocking the rss or atom feeds when my site was in maintenance mode. Let me remind myself of my solution and post again when I’ve reviewed it.

Last edited by net-carver (2009-07-18 16:03:03)

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)

Textpattern CMS

Textpattern CMS support forum

#76 2009-03-12 13:58:57

Re: rvm_maintenance (v0.5)

#77 2009-03-12 15:20:00

Re: rvm_maintenance (v0.5)

#78 2009-03-12 18:18:20

Re: rvm_maintenance (v0.5)

#79 2009-06-07 18:52:08

Re: rvm_maintenance (v0.5)

#80 2009-06-13 06:26:04

Re: rvm_maintenance (v0.5)

#81 2009-07-18 08:18:56

Re: rvm_maintenance (v0.5)

#82 2009-07-18 11:59:45

Re: rvm_maintenance (v0.5)

#83 2009-07-18 13:50:00

Re: rvm_maintenance (v0.5)

#84 2009-07-18 15:24:54

Re: rvm_maintenance (v0.5)

#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)

Board footer