Leaderboard

Page Edit Per User takes the approach of first checking if PW says the user can edit a page, and if the answer is "yes" it returns early and doesn't apply any logic after that. So it only ever adds edit access and never removes it. For your scenario I think you'll need to approach it differently and give the role the necessary permissions to edit, create and add children for all pages having the templates in question. Then in your hook remove the edit/add permission for individual pages according to your test for when the user is not allowed to edit or add children. You do that in hooks to Page::editable and Page:addable by setting the event return to false. And in contrast to Page Edit Per User you'll only need to apply your hooks to users with a particular role. So your init method might look like this: public function init() { if($this->wire()->user->hasRole('limited')) { $this->addHookAfter('Page::editable', $this, 'hookPageEditable'); $this->addHookAfter('Page::addable', $this, 'hookPageAddable'); } }

Hi @Mats i had been fighting for a while with this too and ended wrting my own solution to keep some hair on my head ? and my pleasure of course have a nice day

Just to say, that 4.0 beta is working just fine. I had to tweak jquery migrate, but this issue will be fixed soon.

You might find this useful: https://processwire.com/modules/page-rename-options/

So, I've bumped into something worth considering. When I added more languages to my client's site the existing pages inherited the untranslated URL slugs from the default language. So I've got to go to the Settings for each page and manually click the translate from English button for each language to pull a translated slug. That's burdensome, but it seemed to be working... until I had to start translating a bunch of blog tags, then some slugs wouldn't translate. I couldn't figure it out until I realized that Fluency must be pulling a DeepL translation from the English slug, not the English title. You'd think it wouldn't matter, but it does. Here's an example: English > French: AI App > Application IA ai-app > ai-app It turns out DeepL translates ai-app to ai-app in every language. I don't think it knows what ai-app means so it just returns it. I don't know how commonly people will run into this problem, but I've been running into it a bit. Sometimes DeepL will return the slug unchanged, sometimes it will provide a slightly different translation than it did for the title. My suggestion would be for the slug translation prompt to use the default language page title when calling for a translation. I could see where pulling the title could create other surprises, such as when someone has the page title "Contact Us" but the slug "contact" they'll be getting longer slugs returned. Still I think that would be preferable to DeepL just silently failing. Maybe others feel differently. It's worth consideration though.

@BoostGuess stability, security and privacy data protection. I don‘t like my IP send to CDN servers and for some of my customers this would be a no go at all.

So, @da², @MarkE, @gornycreative, thanks to you guys, I am able to do what I aimed for. Once again, I’m baffled with ProcessWire API smartness and simplicity. Thanks you again, guys.

@zota Hi, our little conversation hit a zone in my old brain and i ended creating a little plugin that may be useful for your need https://github.com/virtualgadjo/pw-tinymce-div-plugin just in case ? have a nice day

Hi, i think that using this method you'll probably run into the same problem i did, you insert a div but can't wrap several p inside it and, if ever you hit enter, it will just cerate another div same thing if you select two or three p and try the div option, it will simply transform each p into a div fortunately Ryan's article helped me find the right solution, here https://processwire.com/blog/posts/using-tinymce-6-in-processwire/#example-of-configuring-the-template-plugin a few tries later i ended with this kind of thing { "add_toolbar": "template", "add_plugins": "template", "templates": [ { "title": "Wrapping div", "description": "add a div with content", "content": "<div class='foo_wrapper'><h3>zi fabulous title</h3><p>a paragraphe.</p><p>an other one just for fun</p></div>" } ] } now you have a div with rich content you can modify, add other p or whatever you need, just click where you need it in the field and hit the template button, job done you may have noticed that the class is wrapped with single quotes for json reasons ? but when you insert it in your field tintmce changes them into double quotes by itself in case it helps have a nice day

Gutenberg is.. okay. It's getting mixed reviews https://en-gb.wordpress.org/plugins/gutenberg/#reviews. The trouble is, it allows the user to do too much. It's trying to sit in the middle ground of a page builder and an editor. I think giving the user everything even if they don't need it isn't inline with ProcessWire. Things like being able to make columns etc. I actually much prefer Statamic's implementation with it's Bard field - https://docs.statamic.com/fieldtypes/bard