adrian

Hey Joss, I am personally not a big fan of the Add New button at all - I know it seems like a nice shortcut, but for some reason it just seems more confusing to me than anything. I am sure others love it though Anyway, my point is that even though I don't like it, it is the PW default to have templates appear in here if all the conditions are met, so wouldn't most people expect this behavior and would prefer it wasn't overridden by default? Maybe it should be another configurable option when setting up a new Page field? I'd add it at the end, below "Allow new pages to be created from field?" What do you think - does that seem like the best option?

date("F", $test->getUnformatted("testimonial_date")); // October Check out the php manual for other codes to use in place of "F": http://php.net/manual/en/function.date.php

Actually, on second thought (distracted thoughts while working on something totally non-PW), I think a test send would be a good idea - would be nice to see exactly what the users will getting emailed to them. Might take me a few days to get to this, but I will get to it as soon as I can.

Hi davo, Pretty busy here this morning, so just a quick reply to say that I think email test sending is probably better left to one of the WireMail modules: http://modules.processwire.com/modules/wire-mail-swift-mailer/ or http://modules.processwire.com/modules/wire-mail-smtp/ I think they both have a test send function, although there might be some reliability issues with that - there is a couple of posts about that on the support thread for the latter module (the one by horst). Are you getting any emails sent from your site at all? If any work, then the ones from this module should work fine. Let me know how you go and I'll try to have more input later.

I thought about doing realtime with PHP using http://elephant.io/ but ended up going with nodejs and meteorjs. I hate being away from PW, but sometimes you gotta do whatcha gotta do

In case you haven't noticed, in PW 2.5 if you click the move icon, a trash icon appear on the far right of the screen - pretty nice shortcut option!

Definitely one of those two modules - if it happens on page save then it's the former. If it happens in realtime then it is the latter. Anyway, they should both be fixed now. You should be careful using those two modules together - one will override the other depending on your requirements. Again, sorry for the hassles. EDIT: Looks like our posts crossed - but glad to see it is working for you now!

Not that soma's advise ever needs someone else's support, but I am in complete agreement - this approach is something I have done on several sites - it works great and saves lots of hassles and just seems more kosher.

Enable the core module "Page Path History" and it will take care of the redirects for you.

I've always been using it too - I have just seen several comments throughout the forum saying things like "while the module directory updates, please grab the latest version from Github", so I thought I'd mention it for those that don't know. Agreed - we need to go through and tag our modules with 2.5 where appropriate. Lots of other things need doing with the modules directory too like making it more obvious what the version compatibility is from the summary page, rather than having to view the details page. But these things have been discussed elsewhere.

Just a reminder to all the module devs out there. If you commit an update to your module to GitHub, you don't have to wait the normal day or so for it to be updated in the modules directory, Modules Manager, Check for Updates link, and the in new Upgrades Module. You can simply edit the module in the modules directory and save it again. That should update the version from Github. If you are using the info.json approach then just manually edit the version number. Often this is not that important but if you discover a critical bug and want to make sure people can get the new version easily and immediately, this is a good idea!

Chris, This is a total stab in the dark here, but any chance you also had either the AutoName or PageRenameOptions module installed? There was a bug in both that allowed for system template names to be changed - would only happen to the user template if the title field was added (it's not there by default, but it is added with this module). The bug has been fixed on both modules as of today, so if that was the issue, make sure you update those modules and everything should be fine. The good thing to know is that it would have just been a matter of opening up PHPMyAdmin to see the name of the user in the database - log in with that and you'd have been fine. So very sorry if it was one of those modules that caused the problem, but glad you managed to restore things ok. If not, I'll defer to kongondo.

Yeah, but your option is way nicer once you get to more than a couple of options like this

You are not using a PW selector. This needs to be in PHP syntax: if($page->template->name == 'home'|| $page->template->name == 'project' || $page->template->name == 'projects' || $page->template->name == 'posts' || $page->template->name == 'partners'){ But maybe instead you could see if the $page->sidebar actually exists. Maybe that won't work in your scenario, but thought I should mention it just in case.

Thanks for your thoughts Antti. As for the 20 000 pages recursion writing to the database - admittedly I haven't studied the PagePathHistory module, but from what I have seen, it only stores the path to the parent page that was actually changed, eg news with the id for the page which is now named latest-news. It doesn't store rows for each of the child pages. Or sorry if I am missing your point? Ajax polling is definitely a good point, although I don't usually have pages that are called via ajax editable by non-superusers, but I guess this could definitely be an issue in some cases. I like to plan too, but clients often don't

Why does it break ithe 20000 news items if PagePathHistory is installed. What doesn't it work for ? Is there something I haven't come across yet that we all need to know about ? Whether they should be installed on a live site is a matter for each developer, but during development I do think that a tool that matches the name to the title is very useful.

https://github.com/ryancramerdesign/ProcessWire/blob/576a5d30153f045daa94a136a6ba981650632b26/wire/core/WireArray.php#L833

What about: $editpage->ad_publish_at->removeAll(); I haven't tried it with a custom table like this, but I think it should work.

Yes, you can call $pages->imagefield->first()->url or $pages->imagefield->eq(n)->url in separate spots in your template, but that doesn't mean it is easiest in all situations. Typically using one images field with support for multiple images is good for sliders/carousels and image galleries, and for insertion into body text, but if you are talking about wanting to add a specific sidebar image and a main article image or similar setup, I would go with two separate image fields set to support only one image. It really depends on your scenario and what works best for you and your clients.

Does it really matter so long as you have Page Path History installed given that it automatically sets up 301 redirects? I think some users would definitely like the rename only on first time / initial publish. Thinking about compatibility with PageRenameOptions - I think the key settings would be "Initial Differences Protected" and "Live Changes Protected" along with the role based exemptions for these rules. I guess the biggest problem is that your module works on page page, whereas mine with via JS to change the name on the fly. It might actually be a bit of a challenge to reconcile both. Also, I have a bug for you - your module is also affecting the names of users - I expect there might be other things to that will be changed by this that shouldn't be.

If you're in a rush, try this in Modules.php at line 837 Note: Fully untested if($info['name'] != 'ServicePages') is the new bit. if($module && empty($options['noPermissionCheck'])) { $info = $this->getModuleInfo($key); if(!empty($info['permission']) && !$this->wire('user')->hasPermission($info['permission'])) { if($info['name'] != 'ServicePages') throw new WirePermissionException($this->_('You do not have permission to execute this module') . ' - ' . $class); } }

There are two things going - the enter button I think has always done that - definitely annoying and needs to be fixed. The SEO module hasn't been approved yet, so it won't be available to install via class name. The easiest way is to use the "Add Module from URL" option and enter this: https://github.com/NicoKnoll/MarkupSEO/archive/master.zip

Glad you got the permissions sorted out. I have filed a feature request on Github for adding those links to the info pages of installed modules: https://github.com/ryancramerdesign/ProcessWire/issues/746

You make some good points. When installing a module you see a screen like this: I think it would be great if the: Links More Information / Project Page / Support Page section that is present on this page was also present when viewing the details of a module once it is installed. I definitely think this is something that should be added and gives direct one click access to all the pages related to the module. Sorry for the "could not remove" errors you are getting with those two modules of mine although it sounds like a file permission problem on your server. Would you mind telling me your apache owner, the chmod values of those two files that won't delete, and their owner/group.

Oh how I miss the Blueys