adrian

Thanks for the report - can you please try the latest version I just committed and let me know.

Quite possibly - have you checked that the $eventpages array is containing the pages you are wanting to delete? What about if you add "include=all" to the selector?

A really cursory look suggests it's because of $pages->trash - remember $pages is not available inside a function. Try wire('pages') like you have above.

It sounds like it is an allow_url_fopen issue. Edit your php.ini to set it to "On" and the module should work fine.

Not specifically - I thought about that, but AFAIK, only superusers can see/edit the Admin page tree anyway, so I don't think it should matter, but please let me know if you discover otherwise.

Thanks for the report and sorry about that - looks like I introduced a bug in my commits from yesterday. Should be fixed now in the latest version. Please let me know if you still have any problems.

Yes they are disabled by default, but I just added a new option under Content / Deletion / Protection to enable BCE editing of the Admin page branch. Obviously this has the potential to completely break a PW install so use carefully at your own risk

Just incorporate one of these: https://gist.github.com/jakebellacera/635416 https://github.com/hising/ics-generator Have a go and drop a line if you have any problems.

No problem at all. Welcome to the forums btw. I am sure it will all start to make sense very soon!

In this case you probably just want: $session->redirect( $page->redirectTo ); because a URL field doesn't have a url property - it's just a string.

Just wanted to let you guys know that I have committed some changes over the last couple of days that brings complete live updating of child page details (name, template, hidden status, unpublished status, and removal of a row if deleted) in the edit mode table after making edits to a specific page in a modal popup. It might not seem like much, but it makes this mode much more functional and intuitive. Please let me know if you notice any problems.

Just a quick response - you might find this ORM module by teppo interesting. http://modules.processwire.com/modules/red-bean-php/

I am curious why you want to change these, but if you really have a good reason, I think the easiest/only option might be to edit the htaccess file in the PW root, or add htaccess files in the sub directories that you want to change the protection on. This should override the protection added by PW's root htaccess file.

Just in case you don't know, there is a setting under your forum profile for automatically following topics that you post to.

I like where you are headed with this Tom. One of the things that I find still quite cumbersome in PW is the need to return to the Page Tree after editing a page so I can find and edit the next page. Having the tree in the side menu would be a huge timesaver in my opinion, and also just help the user to visualize the site structure when they are editing a page - they can see where the page fits - context can often be very helpful in a complex site. I have actually been thinking about this today too and my thoughts are that the Setup, Modules, Access items should be along the top (like the default theme). Then the page tree could simply be in that side menu - no need for a second side menu. As far as implementing this, I don't think we need to have ajax loading of pages when clicking the edit butt on a page - it can simply reload the entire page with the page tree open to the page that is being edited. I also like the color scheme - matching the recent PW dev mockups.

Right - sorry I really didn't read your post properly I think you will need to roll your own. As mentioned above there are several databases available (some free) or services that can allow you to match a user's IP to their location. I also have to strongly agree with @BitPoet - be sure not to annoy the user and make assumptions - always give them an option.

Don't forget about the "Add Children" permission on the parent template.

Is this what you are looking for: https://processwire.com/talk/topic/8733-autodetect-language/ Sorry, not a multilanguage users, so I might be misunderstanding your needs.

There isn't anything else for previewing an entire page of output. Are you interested in this functionality for seeing changes to already published pages, or just in general to save going to the page on the front end? If it's the former. perhaps Ryan's upcoming Drafts module (https://processwire.com/blog/posts/processwire-2.6.13-and-a-preview-of-prodrafts/#about-prodrafts) might be useful. I haven't seen it in action yet, but from reading the post, I think it is possible to view a draft version. Would this take care of your needs?

Please note that Nico has marked this module as "Discontinued" on its Github page: https://github.com/NicoKnoll/ProcessPreview. Obviously you could fork it and make the changes to get repeaters working, but just wanted to let you know his intentions with it.

Thanks @videokid for the explanation. I have just committed an update to the module so that it won't overwrite the name if the result will be empty. Hopefully this will allow it to work in this multi-language situation. I appreciate knowing if it now works for you as expected. I honestly don't know how anyone makes it through the development phase of a large site without this module - I would end up with so many mis-matched titles/names - the editors I deal with never remember to change the name to match. Thanks, Adrian

I haven't read through to determine if there is a complete solution yet, but please read here: https://processwire.com/talk/topic/11685-page-tree-not-visible-in-backend-after-installation/

Thanks for the update. But PW doesn't handle creating a page name from that title in the first place - the name stays blank and you have to manually enter a name. If this also what you experience? Sorry, I don't ever use the Multilanguage stuff, so not completely sure how it all works. The one thing I could probably do would be to not change the name if it would end up blank, but I want to better understand what PW normally does when entering a page title like that.

There is a protect hidden pages option in PageProtector. Or you could do: if($page->isHidden()){ throw new Wire404Exception(); } but I am not sure you whether you actually need to give users access to these hidden pages or not. With PageProtector logged in users will be able to see the hidden pages, so maybe that is OK for your use case?

In case you can't find the code for logging in with email address, here are two options, both with pros and cons: https://processwire.com/talk/topic/1716-integrating-a-member-visitor-login-form/?p=89599 https://processwire.com/talk/topic/1716-integrating-a-member-visitor-login-form/?p=89616 (my preferred option)