JayGee

I'm thinking of using the comments fieldtype for a very basic support ticket system for a project. I guess I can just hide the fields and populate them using JS or something - I'm just wondering if it's possible out the box to disable the name/email fields and use the current logged in users as the comment poster instead without hacking at it. ?

You know what - I can't even remember now if/how I resolved this! ?. But the answers from @d'Hinnisdaël and @adrian are cool for future reference as I had never even noticed you could use regex in the allowed URL segments so that's great to know.

Hi all, is it possible to setup an inline frontend edit on a FieldsetPage field? It works with <edit> tags, but can't make it work inline. Have tried the following to no avail. (Header is the FieldsetPage). TIA. <?=$page->edit('header.simple_text3');?> <?=$page->header->edit('simple_text3');?>

I think I can also implement pseudo enforcement by not dishing out roles to users until they opt into the suggest 2FA. ?

No probs thanks for your help. This is the first time using PW 2FA on a client project and just making sure I get my facts straight before looking like a fool ?

Ok I was only on latest master. Have updated and now have the options screen in that blog post. But unless I'm thick I still can't figure out how to force TOTP? I see you can 'strongly suggest'. I see Ryan wrote Has it just not happened yet?

What's the best process for adding another user with TfaTotp 2FA? Just using it for the first time. Should I supply them with them with the secret when I first create their account? Seems like a security risk? Otherwise how do I create a 2FA user and let them login for the first time?

I think you can still store HTML in Editor.js. So I wonder if it might be feasible to add a new editor field alongside CKeditor ones then use a hook to copy the content over on page save... or something like that anyway!... I'll be looking to address the same issue if this module works out.

Ok this is awesome then - best of both worlds! One other feature request that will make this a killer module IMO... that it should work with Front End editing.

This looks cool. One bit of feedback (and this may just be my opinion rather than a general consensus) but I really dislike how the WP Gutenberg treats every paragraph as a block. To me it makes no sense to be able to rearrange text at the paragraph level. To me a single block of text with multiple paragraphs within it seems more sensible. Although looking at the example JSON doc on the Editor JS homepage it looks like it treats every para as an element and for ease of maintenance I guess you won't won't want to stray too far the default behaviour.

Amazing thank you! Works like a charm. ?

I did try this and couldn't make it work - wasn't sure if something special about repeaters? Just want to call this repeater and include the all of them even if hidden/unpublished. $store->products->sort('title'); I did also try: $pages->find("template=repeater_products,sort=title,include=all"); but nada ?

Is there a method or a selector for including unpublished items when outputting from a repeater field?

Finally got onto trying this out and confirm fix works - thanks for your help ?

Ah thanks @matjazp - I'll try applying those fixes later as I presume they're currently only in the dev branch? I'm working on a master copy downloaded yesterday.

I seem to be running into a repeated fatal error in a fresh PW install version 3.0.148. I can't quite put my finger on the pattern but it seems to be around deleting image fields or removing images from certain image fields. This is the trace from the log generated by trying to save a page and delete an image from an image field: Fatal Error: Uncaught Error: Cannot access protected property Pageimage::$original in /wire/core/PageimageVariations.php:256 Stack trace: 1. /wire/core/Pageimage.php(1327): PageimageVariations->getInfo() 2. /wire/core/Wire.php(386): Pageimage->___isVariation() 3. /wire/core/WireHooks.php(823): Wire->_callMethod() 4. /wire/core/Wire.php(450): WireHooks->runHooks() 5. /wire/core/Pageimage.php(1369): Wire->__call() 6. /wire/core/Pageimage.php(399): Pageimage->getOriginal() 7. /wire/core/WireData.php(333): Pageimage->get() 8. /wire/core/PageimageVariations.php(256): Pro Line 256 of /wire/core/PageimageVariations.php Earlier in the day I was experimenting with custom fields for images for the first time and kept running into this error, thinking it was me using this feature wrong and not having time to read up I deleted the custom image fields template and went about my business. So now I don't know if I triggered an issue or whether it was never related to the custom image fields in the first place? Any ideas?

Interesting I hadn't considered that. I was wondering - could I just change the admin template permissions in the access tab to exclude the roles I don't want to give backend access to? Any unforeseen consequences here? ?

Yes sure I can make something work here thanks. Love these kind of simple approaches - I was way overthinking it!

A beautifully simple approach thank you! ?

As per the title really, is it possible to set up front end editing permission on a template without granting a user access to the back end dashboard? I know I can allow editing with the API but seems to be reinventing the wheel somewhat!

I have installed this module on a site that uses URL segments on the home page. I don't seem to be able to access /sitemap.xml - it just redirects back to the homepage, presumably the path is being treated as URL segment. Is this expected behaviour or do I have something set up incorrectly?

Thank you - I can confirm I managed to log in too now, but had to go Incognito to get it to come back to life otherwise it just looped back to the login screen with no messaging. Presumably something to with session info related to my account as above.

Thank you. I did try most of the different ways of including files. The problem wasn’t with the include itself which was working fine. The include itself was running some PW selectors and dynamically populating some variables critical to the rest of the page content. Seems that with a standard include things weren’t loading in the order I needed for this to work, but using an appended init file works fine ?

After some sleep I answered this myself by prepending an _init.php file in my config with the include in ?

I'm experimenting with markup regions for the first time instead of static output. Everything's going great other than I can't work out how to include other PHP files in my _main.php file that use PW functionality. Primarily I have a script that runs some checks against user permissions and runs a few PW selector queries to set up a few useful variables for a basic web app. If I include this file into my _main.php the variables don't populate as it doesn't have access to things like the PW $pages object - presumably something to do with the load order? What's the correct way to go about this, a new module seems overkill. Is it just a case of including the file at the top of every template, or is there a smarter way?