adrian

Speaking from experience, can I suggest running away very fast from JQM - check out Ionic instead

Try HookEvent instead of hookEvent

@Tom - that setting will appear once you check one of the fields. Ryan - the one thing I am noticing is that there is no way to choose B,C, or D. Nevermind I see that you don't need to choose the other options! But, I am also wondering what you think can be done about this: Notice the area of the paragraph - that translates into the area that is triggerable for edit mode by double-clicking - so the user mouses over the bottom half of the image and it looks like they can double-click on that and edit the image, but they can't - it just makes the paragraph editable.

Here is a discussion about the problem and link to the commit that fixed it in Oct: https://github.com/ryancramerdesign/ProcessWire/issues/1451

Still no problem here on 2.7.2 (the latest stable version) and 3.0.2. Is there any reason you are still on 2.6.1? Not saying that is the problem - I don't remember any changes that might have affected this, but might be worth a shot, and you have nothing to lose - there are so many great new features in 2.7.2. If you don't already use it, check out the Upgrades module as a simple way to update: https://github.com/ryancramerdesign/ProcessWireUpgrade

I have seen several drupal sites where the link in the html is still the /node/nnnn - does that mean they don't have it configured correctly or is this just something that is unavoidable in some cases, in which case that seems worse from an SEO point of view to me than just redirecting outdated links with PagePathHistory keeping in mind that there won't likely be that many changes - seems better than redirecting every /node/ link if it isn't being rewritten properly before the HTML is generated. However, a textformatter to rewrite ID links made by this module wouldn't be hard to put together - in fact I bet you could steal some code from the Link Abstractor module - which btw is now deprecated. If go to tackle this and need some help, please let us know and we'll help you get it working.

No problem doing that here. What version of PW are you running?

It seems to work just fine, but isn't officially supported, so your mileage my vary depending on your setup.

This sounds like a bug / oversight - perhaps you should file a Github issue about this.

Hi @gmclelland - to be honest I don't really use this module for replacement of the main links - I only use it as a means of providing a shorter URL if required. I actually think that the Page Path History module does an excellent job of preventing broken links. I have never actually been a fan of Drupal's /node/nnnn/ links, but in previous custom systems I have built, I have included the page ID as part of the URL, like: mydomain.com/nnnn-title-of-my-page/ which this module allows. As for changing the insert link - this should already work - at least it does for me: Sorry if I am missing your point - in a bit of a hurry! PS Did you select the "Rewrite Links" in the module settings?

What about this setting in Advanced Mode: Modules can accomplish almost anything - if you are willing to make a start, I am sure you will get plenty of help if you need it. There might be something useful in this thread: https://processwire.com/talk/topic/3543-register-users-and-add-page-same-as-username/ You might also like to look at the way the EmailNewUser module triggers an email when a new user is created - you might be able to use that as a starting point for modifying to create the member page instead.

Thanks for the report @ukyo - sorry that you and Ryan spent time debugging this. I have committed a new version which appears to fix the problem for me. Could you please test and let me know if it now works for you? If anyone is interested in what the problem was, take a read of the Github issue.

You wouldn't need another full module, you could just use AdminRrestrictBranch and add an additional hook that is triggered when a new user is added which takes care of creating the member pages. But, what I would do is use the "Multiple templates or parents for users" ability instead: https://processwire.com/blog/posts/processwire-core-updates-2.5.14/#multiple-templates-or-parents-for-users That way the member page is the user page, so one less thing to create and maintain. Sorry my answers aren't complete with examples today - lots to do and not much time

Could you put the X, Y, etc branches under an extra parent and just add that to the branch edit exclusions - that will take care of making all new ones excluded. I would suggest that AdminRestrictBranch might still be useful for you - you just need to add an additional hook somewhere that will automatically create the required branch when the user is created - this should be very easy - let us know if you need help. You might also consider connection the user to the parent branch by one of the other options - role name or PHP custom code - this might be able to automate this process for you. Good luck with whatever approach you choose!

I guess my question for you, is does it work as you want? Seriously though, I think it should, but if the editors need to directly edit pages under Section X then you would need to use the "Editing Only" option, so that the page tree view is not actually restricted. With that setting, I think it should work as you described - how did it work out? Was there anything that didn't work as you need?

I think I must be missing something - have you tried the AdminRestrictBranch module? Can you please highlight exactly what it doesn't support for your needs - perhaps they might be a worthwhile addition, or perhaps not

@clsource - fantastic writeup - thanks for sharing!

PageTableExtended can be used for generating previews: http://modules.processwire.com/modules/fieldtype-page-table-extended/

Sorry Jon - just realized I didn't answer the last part of your question. To read more about ready.php, take a look here: https://processwire.com/blog/posts/processwire-2.6.7-core-updates-and-more/ I think it is much easier than setting up a module for custom tweaks like this and I don't think there are any disadvantages. Actually, for admin specific stuff (assuming you aren't saving your pages via the API), you might actually want to put that code in /templates/admin.php so it is only called on the backend.

You can click the Download Zip button on this page: https://github.com/ryancramerdesign/ProcessWire/tree/devns Or use the Upgrade module: https://github.com/ryancramerdesign/ProcessWireUpgrade to get it.

There is a little info on SaveReady here: https://github.com/ryancramerdesign/ProcessWire/blob/dev/wire/core/Pages.php#L2293 With save you need to be careful you don't end up going recursive which can happen when hooking after save because your hook function then needs to call save again, which triggers the hook again Maybe hookbefore save would be ok - I don't actually recall - I just tend to default to saveReady because it usually suits my needs!

I haven't come across this - I wonder if it's the fingerprint config setting - try setting that to false and see how it goes.

Try something like this in your ready.php: $this->pages->addHookAfter('saveReady', null, 'buildName'); function buildName($event) { $page = $event->arguments[0]; if($page->template != 'cruise') return; $page->title = '$page->parent->title . '-' . $page->date . '-' . $page->boat_name'; $page->name = wire('sanitizer')->pageName($page->title,true); } EDIT: You may also want to make use of the Name Format for Children option so that the page title/name initial dialog is not needed. You could have this set to create a dummy name since the code above will rename after anyway.

Actually I just realized I might have been a bit confused by what you want - I thought what I wrote answered the first sentence in your question, but the second sentence suggests you want to hide the pub/unpub action buttons, in which case try this in your ready.php $this->addHookAfter('ProcessPageListActions::getExtraActions', null, 'hookGetExtraActions'); function hookGetExtraActions($event) { $page = $event->arguments[0]; $extras = $event->return; if($page->template->name == "basic-page" && $page->hasStatus(Page::statusUnpublished)) { unset($extras["pub"]); } $event->return = $extras; } You can remove the page status check for unpublished and also add: unset($extras["unpub"]); if you want to remove that as well.

I think you should be able to achieve what you want by hooking into Page::editable I think this should do what you are looking for - just edit the template you want to match. Keep in mind that in this form it will even prevent superusers from editing the page, so you might want to check that before adding the hook $this->addHookAfter('Page::editable', null, 'hookPageEditable'); function hookPageEditable($event) { $p = $event->object; // in case there is already a defined exclusion for this user's role for this page if(!$event->return) return; if($p->template->name == "basic-page" && $p->hasStatus(Page::statusUnpublished)) { $event->return = false; } else { $event->return = true; } }