Pete

I was going to say that some sort of insulation would be good as you said Martin. Not everyone will understand Git, but I think they might be far more likely to be able to get to grips with Pw so some simple way of installing modules would be the way to get around this. In fact, thinking out loud (and I'm sure some of this has already been discussed elsewhere on the forums), could the first version of the modules directory simply contain module info, author info, screenshot (if neccessary) and the link to the direct download link on GitHub (if their terms allow this) else a link to the download page for the package on GitHub. A later stage would be a fancy module installer I guess, but something like the above would suffice for now I think. I'm also assuming something slightly more complex could be done assuming you can pull the number of downloads from GitHub using their API?

In which case it would make sense to be able to set that on a per-template basis I think. Label fields for single and plural versions would make sense in case the template name isn't properly formatted to be a tab title (sometimes mine aren't at least).

That's a good idea I think. My first thought was that it might make things less intuitive, but then that all depends on whether someone chooses a silly name for the child template. I would suggest that it maybe be configurable somehow rather than automatically done else it might take some users by surprise.

This is a great idea! I used to use a CMS system when I worked in a local government department and they weren't in fasct allowed to use any CMS system that didn't contain this functionality, otherwise important content might never get updated. Would be good to even be able to set this in page settings and have child pages inherit, so for a news section it doesn't need a reminder of any type, but for informational sections you could pick 6/9/12/24 months. I think this would be good to have as a module definitely. Another thing the local government CMS did was actually have the ability to email the author, so perhaps a once-a-week round-up of pages that need to be updated soon or are out of date. The big problem I can already see with it though is how to you mark it as "okay" if there are no changes other than saving the page with no changes? That solution would be undesirable as people might expect the content to have changed in that case. Maybe a table that tracks "last checked" dates?

Updated to v 1.0.4 to make redirects temporary (302) instead of permanent (301) - original post contains the updated file. Thanks to ryan for pointing that out.

Just a thought - but the next step might be image tagging like FB? Not sure that falls under the remit of a separate module but I can think of lots of places where that might be useful, though I appreciate that a lot of the time it won't be.

Cheers Ryan - i'll update the module tomorrow.

No problem. The default header code for redirects in PW is a 302 redirect (page has temporarily moved) which is actually the default code for a redirect in PHP itself. The 302 (the way it currently works) might actually the best header anyway as it tells search engines to always check the original URL for a page next time it visits despite the redirect and that the redirect is only temporary. I don't think it affects SEO in any way looking at it - as long as maintenance more isn't left switched on for months of course A 503 suggests the actual server is down for maintenance if I'm reading the description right on Wikipedia, although I see it says it's only temporary: http://en.m.wikipedia.org/wiki/List_of_HTTP_status_codes

Oops - that message you got about the maintenance status was a debug message I left in and might have been the cause of some of your earlier problems, although if it works on a clean install I'd guess the module wasn't causing the issue. I've removed the offending line and updated the original post with the new file which should be version 1.0.3 now. It should be possible to add the option for it to return a 503 - I could into that early next week if I don't get around to it today. My only thought on that would be that most folks who don't know what error codes mean might just think the site is broken.

No problem - I understand what you mean now. I just tried that, and apart from it redirecting to a "404 page not found" page when you save the admin page with the new URL, I was still able to create a new template okay when I went in via the new admin URL. The module redirects to the value of config->urls->admin by default, so it actually won't matter that the page name has changed (internally PW knows the ID of the admin page so it gets the correct admin URL that way - pretty sure that's how it works). What browser and and browser version are you using? It's a long shot, but that might help me to reproduce the issue.

Hmm... can't reproduce your error on my install - I just updated to make sure I had the latest PW download from GitHub as well just to make sure. What do you mean when you say "I changed the loginurl to admin"? Do you mean you installed the module but didn't specify a maintenance page? Or did you actually specify the maintenance page as the admin page? Also, do you have any other modules installed that aren't part of the base installation? Hopefully one of these things will be able to help me track down any issues and we can get this sorted out for you. Can someone else double-check and see if they get a blank screen in the same way Jeroen describes please?

No worries - that's what the community is here for

I'll have a look in a bit and get back to you.

You should be able to do something like this to get an array containing your tour operators: $touroperators = $fields->find("touroperator"); A similar example is on this page: http://processwire.com/api/selectors/ Basically you can use "find" on pretty much anything - templates, fields, users and pages by prefixing find with the object you're looking for.

Okay, updated the file in the original post to version 1.0.2 If the module is installed and you view the maintenance page when you're not logged in as an admin, it takes you straight to the homepage, so that should solve your scenario Diogo. I figured admins might want it to actually render the maintenance page rather than redirect in case they're actually tweaking the look and feel of the maintenance template file and want to see the output I also switched the hook to run before Page::render instead of before Page::loaded - difference being that if you do before Page::loaded it runs the hook whilst iterating through all the parent pages in the tree to get to the current page, whereas adding the hook before Page::render seems to just run it for the final page in the tree, which is what we want. I just thought I'd mention that in case anyone needs to know for future module-writing This last part also means that the module now works for a maintenance page that's not in the site root - prior to this if your maintenance page's parent wasn't the homepage then it would just fail to work, which I only noticed today. Not that I imagine you'd put it under another page in the tree, but you never know. @diogo - Going back to your original question, I think you might be asking if it's possible to render the maintenance page without actually changing the URL. That should definitely be possible and might look into it, but the above should work in the meantime. My only worry would be that if your site was in maintenance mode after it was launched and indexed by Google etc, and then Google re-crawled then it would see every page as having the same content. I'm not sure if there is a similar issue either way though as I suppose it would see all pages redirecting to one maintenance page as well the way it currently works. I guess if you turn this on after the site is launched and indexed then I would suggest doing maintenance fairly quickly

Glad to hear you're finding it useful I think the simplest solution there would be to get the maintenance page to simply redirect them to the homepage once the site is live - a simple php header in the maintenance page's template file should do the trick. I'll look at adding a line or two of code so that it maintenance mode is switched off then it redirects silently to the homepage if the maintenance page is requested when I get some free time.

Does IE8 have a compatibility mode button (can't remember) and does this solve anything if it's toggled? Granted it's more likely to introduce other issues but you never know and if it does work even those on corporate networks should be able to switch that on. Sadly I don't have IE8 to test it myself.

I think you're right Everyone was very friendly and eager to talk about ideas and concepts in that discussion which is nice to see as to me that's what open source should be about.

I can do the British English translation - en-GB

That really is a very useful link - thanks! @ryan, any chance of a "coding chat" forum where we can group the more code/programming related tidbits like this together? I've seen/posted a few others in here.

No worries - least we could do I'm sure

This has reminded me that I've had similar issues with MODx like this before - some server security modules have really tight rules (usually mod_security) and won't allow HTML to be inputted via forms. In my case there were several rules causing the issue and I was able to ask my host to alter the rules to allow posting HTML in forms so it's worth a shot asking them if you can.

I think you're right slkwrm - definitely not a good first impression if that's your native language at the very least! I edited mine too.

Guessing you're referring to the new site design?

Hehe, except I posted mine twice because I thought the form was broken and both are now up there. Sorry for hogging the page guys!