adrian

To be clear, PageRenameOptions does a lot more than fix this issue, and those in @teppo's camp who don't want URLs to ever change might think they shouldn't use it, but it comes with this option: which I think makes the module useful for anyone/everyone and actually I think even with this checked, it would solve this copy/clone issue because the cloned page is unpublished and so as long as the title is changed before it is published, it will still rename the page when changing the title.

There are several places that 128 is forced: https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/core/Sanitizer.php#L415 https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/core/Pages.php#L85 https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/core/PagesNames.php#L49 https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/core/PagesNames.php#L314 https://github.com/processwire/processwire/blob/341342dc5b1c58012ae7cb26cffe2c57cd915552/wire/modules/Inputfield/InputfieldPageName/InputfieldPageName.js#L60 https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/modules/Inputfield/InputfieldText.module#L258 When creating a new page, it's the JS file that kicks in first and truncates it as the title is typed. You could override the JS one pretty easily (look at my PageRenameOptions for hints on how to do this), and also deal with the sanitizer by setting the name in a hook and resaving, and you could hook into InputfildText::processInput to deal with the dirty length truncation. I think the hardest but might be dealing with nameMaxLength constants that get used in PagesNames.php in the pageNameFromFormat() method. Definitely much easier to see if Ryan might relax the limit, or make it configurable ?

Thanks for your thoughts - I don't see Ryan having a checkbox for this on all page edits - I think there are too many folks who don't think a page's name (URL) should ever change. I guess I am talking about this only in terms of the copy/clone operation because I think it will create a real mess of page names with the current behavior. But again, my module works around this and it's the first thing I install on all my sites so I am not too invested in seeing this change happen but thought if others weren't aware of the way it currently works and don't like it, they might want to submit a Github issue. Any takers?

What does everyone think of the cloned page keeping the name of the source page? I am using my PageRenameOptions module so this doesn't affect me, but I expect most site editors who use the copy button won't expect that they have to re-"name" a new page to match the title.

And there is a matching "field-admin" permission as well: https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/modules/Process/ProcessField/ProcessField.module#L53

Just in case anyone else is interested, this does the job nicely! $this->addHookBefore('AdminBar::getItems', function($event) { $args = $event->arguments[0]; $args['strings']['browse'] = 'View'; $event->setArgument(0, $args); });

Hey @teppo - firstly, sorry about the View / Browse thing - looks like I changed that on my copy a long time ago and didn't remember it was originally "browse". If it's easily hookable, that's great. In regards to limiting edit to only pages the user has created - this is probably not a common use scenario - on the main site for me that uses AdminBar, I actually don't give users access to the admin at all - I use AdminBar as an easy (and powerful) way for them to create and edit content on the frontend. This is also the reason for having a profile edit button here because they can't actually access the one in the admin. And yes, showing the edit link only if they have created the page is only a "displaying the link" change, it's not actually affecting their permissions, but perhaps now that we have the "page-edit-created" permission, I should be using that anyway, rather than the hack I currently have in place on this old site.

It's great to see new life breathed into this module - thanks @teppo. Two things I added to one installation of mine was the ability to edit the user's profile and the other was to restrict them to only be able to edit pages that they have created. Would you consider adding those features? One other thought - I am a bit confused by "browse" vs the old "view" - browse to me suggests browsing through multiple pages, rather than viewing the current one which is what this link does. What do you think?

This is a very old stemming library now so I expect there are better, but I have been using it in production for about 13 years ? so if you don't find anything better, here it is: https://tartarus.org/martin/PorterStemmer/php.txt

I have linked to @teppo's fork and added him as an author on the module.

Guys - I can transfer the entry in the modules directory to @teppo if you want. Or if you're planning on creating a new version with a different name, maybe it's a new module in the directory? Let me know if you want me to make any changes. BTW - I am not a fan of frontend editing tools in general, but this one I actually don't mind providing for the right site - sometimes even for frontend only users.

@tires - I just tested here with a period containing email address and it worked as expected. I think you'll need to debug at your end. Start at this line: https://github.com/Notanotherdotcom/ProcessEmailToPage/blob/6b192fc6e01e50217e8be2b0e48c8745824630ed/ProcessEmailToPage.module#L470 and make sure the message is in that array. Then go inside the foreach and figure out what rule in there is preventing the message from creating a new page which happens here: https://github.com/Notanotherdotcom/ProcessEmailToPage/blob/6b192fc6e01e50217e8be2b0e48c8745824630ed/ProcessEmailToPage.module#L522 Sorry, I think Pete is no longer supporting this module and I don't have much time to help out anymore either I'm afraid. Reality is that the flourish library that this module uses is also abandoned, so this module really needs to be rewritten with an alternate mail library. That said, it still works for me, so you should be able to figure out where the problem is that is affecting you.

Tracy's RequestInfo panel has all the details I think you are looking for:

@tires - could you please investigate where those "period containing" email addresses get ignored? Is the email being read, but not processed, or is it not read at all? Does it help if the "Only Users" checkbox is unchecked?

In case anyone is interested, cloning also doesn't update the createdUser and modifiedUser values. I have submitted an issue: https://github.com/processwire/processwire-issues/issues/927 but in the meantime, I am using: $this->addHookAfter('Pages::cloned', function(HookEvent $event) { $p = $event->arguments(1); $p->createdUser = $this->wire('user'); $p->save(array('quiet' => true)); $sql = "UPDATE `pages` SET `modified_users_id` = '".$this->wire('user')->id."' WHERE `id` = '".$p->id."';"; $this->wire('db')->query($sql); }); Modified can't be changed via the API, hence the SQL. I suppose created could also be done this way, but hopefully this is just a temporary fix assuming Ryan agrees to change the current behavior.

Nice enhancement to the file filtering in the File Editor panel thanks to @tpr that lets you arrow key up and down through results and Enter to open.

@ttttim - have a read of this: https://processwire.com/blog/posts/pw-3.0.135/#step-4-decide-whether-to-to-enable-hsts-section-9f

@tires - that error should be fixed in the latest version - not sure if that helps your issue with deletion of the email / duplicate copies of page creation though.

Hi @Deyan - sorry about that - looks like I broke it a while ago. Should be all fixed in the latest version. Let me know how you go.

@tires - it should already delete messages after the page has been created: https://github.com/Notanotherdotcom/ProcessEmailToPage/blob/548c9bff1d40aee7bf049032f78b301602517772/ProcessEmailToPage.module#L716 Perhaps you can debug why this isn't working?

@teppo - that is what I thought, but I was thrown by the comment for that rule: "After uncommenting, test a URL like domain.com/site/assets/files/test.jpg to make sure you are getting a 404 and not your homepage." Those conditions don't seem to prevent apache from serving up a test.jpg at that path, although it occurs to me just now that Ryan's intention was for test.jpg to be a file that doesn't actually exist - makes sense now! I was also confused by the "prevent PW from attempting to serve images or anything in /site/assets/" - I thought he was talking about subfolders of assets as well. My initial thought was that this rile was actually about preventing hotlinking, so I think I got the intention backwards, hence my confusion ?

Yeah I know - I had a LOT of work to do to fix the queries on a large custom application of mine, but from the reading I did at the time, it was a highly recommended change to better ensure you're getting the results you were expecting. Mine was very data / calculation heavy though, so maybe not as important for typical PW queries.

I know Section 18 isn't new, but it seems like it doesn't work as expected. I feel like it is missing the actual RewriteRule after the conditions, or maybe I am misunderstanding what it's meant to do?

Interesting that Ryan said this when he actually decided to force removal (https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/config.php#L975) of the new mysql default for "ONLY_FULL_GROUP_BY", rather than properly rewriting the queries to work with the new default.

Try the new version just committed. Not currently, but it should be pretty easy to implement - do you feel like having a go at enhancing the replaceShortcodes() method to handle this? PRs greatly appreciated!