BrendonKoz

Hi @gebeer! I'm currently using RepeaterMatrix with SearchEngine successfully, though I'm not using any non-native PW FieldTypes. I did run into an issue where RepeaterMatrix-based fields, if customized by a template to not include one of it's available fields would cause an error and not complete the index. I have a pull request pending for the repository which, in my testing, seems to have fixed the problem. Although I suspect this might not be your issue, I wanted to share on the small chance that it does help.

@Ivan Gretsky Oh... Are you a new maintainer of the original repo, or is there a new repository? Just want to make sure I'm putting it in the correct place. Thanks!

@digitex@torf Just in case you (or anyone else) are still trying to work around this issue: I just had the NaN JavaScript error on one of my sites using LeafletMapMarker that didn't exist a few months ago. In trying to identify the error since there were no PHP errors discovered (though it wasn't in debug mode), I noticed I had, in that time, upgraded the version of PHP from 8.0 to 8.1. On a whim I reverted back to 8.0. This fixed the rendering of the map. Something is apparently not working on the PHP side which is interfering with it passing the parameters to the module's JS initialization constructor. This might not be a proper solution, but maybe a potential workaround (depending on your requirements) until or unless a more formal update to this module, or a successor can be offered. Thankfully (?) there are quite a few people who seem to have used this module, so the need to get it fixed somehow sooner or later will be increased. EDIT: There's a pull request in the module's GitHub repository that might fix this (untested).

That is mighty impressive. I'm going to look this over more carefully later this evening, but (1)that's awesome, and (2)I was apparently looking in the completely wrong place(s). Ugh. 🤦‍♂️ Thank you so much, Robin! This will undoubtedly prove useful now, and in the future. UPDATE: It's 3 days later and I finally had an opportunity to look at this and give it a shot. I'm still lost on how Robin maneuvered through the file structure to identify where to adjust the call - that's some magic there - but I'd just like to clarify one thing: This hook doesn't allow you to target a specific template (PW conditional hooks); nor was I able to find a passed value to access the intended template (I did find a value, but when trying to access it directly, I only got a null value), so unless someone discovers how to target the intended calling page's template, this would be best for overriding only a field that is going to globally be overridden in this manner. Other than being aware of this, it works great!

I've not yet been able to solve this. Most of the methods I can see in the related classes are to include what isn't already included in the result. I'm trying to prevent auto-inclusion from roles that normally would automatically have access. wire/core/PagesLoader's find method, which calls findShortcut, seems to be two places where I'd need to concentrate how to work around, but I'm not sure if it's even worth it to investigate further. It might be easier to temporarily remove role-based access, but doing so within an admin template is the tougher part. The purpose is to prevent specific roles that have access to manage a specific template, to then use a page reference field (which would attempt to directly add the chosen page to primary front-end navigation) to select from an unpublished or hidden page.

It does appear as though it's related. In my instance I'm using PageListSelect which was mentioned as also being affected by this. I'll give the available solutions a try tomorrow. Thank you!

I led you towards where to look, but didn't show all of the involved steps. It actually is able to prevent access. After re-reading everything, it might be too restrictive for what you're trying to do though, so I am glad that you found a way to get things working. I set up a quick PW install just to test this and verify I wasn't remembering wrong, so any images that are shown may be minimal simply because I chose the Blank profile for testing purposes. In this quick test, I did modify the basic-page template simply so I didn't have to create another template, and the homepage is still accessible by any user. Here's a screenshot of the settings, from the access tab of the basic-page template, that restricts access to viewing pages using this template, viewing/accessing any assets belonging to pages created with this template, and preventing search from returning any pages created with this template (unless the user is a super user, since a blank profile only has the super user [default account: admin] and guest roles). Using the settings as shown will not allow access. Setting $config->pageFileSecure wasn't necessary here. This is essentially the same as your Method #1. 🙂 In the settings I show above, I also chose to redirect any guest user to a login page so that I wouldn't have to create any additional templates. Sending someone to a login page is a perfectly reasonable solution, though it might be preferred to send to another page instead (which the template settings allow you to choose to do). When logged in or not (the homepage): When logged in (the basic-page example): ...and when not logged in: ...and when not logged in and trying to access the image by direct URL (which a search engine realistically should not be able to know): https://example.com/site/assets/files/1015/1526898_10152005302794342_1548624436_n.jpg Interestingly, it seems like the 404 for the Blank Profile is redirecting to basic-page which is now supposed to be role/profile locked. I think this is a tiny oversight in the provided files for the blank profile that cause this, and an expectation that basic-page would not be role/profile locked. In a real site, the chances of that happening are slim. (I'm surprised it even rendered it, to be honest; in this instance I probably would've expected a 500 error, so it's actually kind of nice that it forced the render for the 404.)

Template settings (along with role management/assignment in user administration) should handle all of the scenarios you list. Here's a screenshot of the template edit screen's "Access" tab... In the first section, you could choose "Yes" to limit access to any pages using the template you're editing (in this case the "basic-page" template; likely not the one you'd choose) and assign a role, or roles, that can access pages created with this template. The second section would prevent using direct URL access to any file(s) held on pages created with this template. Be default, images and files are associated/stored relative to each page.

I think most of us here would answer this question as opposed to your others, and answer that, yes, it's more advantageous to use inputfields for this purpose. Since in your example your columns are similarly sized, you could use a repeater of a textarea field to handle this, and base the width of the columns you apply in the template code based on the number of repeated fields created (or if you only want to allow a fixed number of fields, you can design it that way too). The benefits are: If the primarily suggested rich text field handling changes with ProcessWire (ex: TinyMCE changed to CKEditor, then is about to go back to TinyMCE), you don't have to deal with recreating code to handle solutions you thought were already solved. The more HTML you allow in the back-end, the more control of layout you give to users that have access to the system. Although there are definite exceptions, typically that's not how most developers want to control the websites they develop for others to use. Separation of concerns. Just like we want to separate styling (CSS), and semantics (HTML), storage (database / filesystem), and interactivity (JS) all from one another, we usually want the CMS simply to be there to handle management of the content so we are able to, more often, know where to find things when something needs to change (benefits for maintenance of the system). What you're doing is definitely possible, but honestly, it's so opposed to how I normally work that I'd have to setup a new installation just to try to work through it with you (which if you really do need the help, I'd give it a shot). For a more thorough system to handle visually creating content, you might have better luck looking at @jploch's new visual builder for ProcessWire, PAGEGRID.

I know that Super Users can see hidden and unpublished pages by default. However, is it possible to force a Page Reference field to only show published, and visible pages - even for Super users? I'd like to just minimize the potential for error with a specific use-case, but can't seem to get the selector correct. I tried the following selector: status!=unpublished, status!=hidden That didn't seem to work for me. In fact that didn't work at all, even in a standard find() call.

I get errors like this that I cannot reproduce more often than I'd like and, because I can't reproduce them, haven't been able to track down how or why they occur. I think it's a race condition based on PHP code running faster than the filesystem (ex: the code says to create a folder, the OS tells PHP OK, code continues, but the filesystem hadn't actually completed creating the folder). When I refresh the same page, I either don't get any errors, or I get a different file/folder that throws an error. Eventually refreshing enough times clears all errors. This is all just a hunch, so changing PHP versions might cause a large refresh of many files and folders of the cache all at once, which could have a higher probability of hitting a race condition like this - if it is indeed what causes the error.

Yup, definitely possible. It can potentially cause breaks in unintended spots which, for certain languages, are just unacceptable, so that has to be considered as well. It's still an option, though. A soft hyphen or <wbr> are options that allow direct control of where breaks should occur, if any, and one must consider what is best for their project and use-case. Thanks for providing the linked resource, aagd! @BitPoet and @Alf S. thank you for reporting back!

I just tested this a bit with HTMLPurifier, and (at least in quick testing) was unable to prevent it (as far as I could tell) from removing the HTML equivalent of the character (using &shy;, or pasting a rendered version of it in directly). Searching the internet as a whole doesn't seem to give much specific information either. Since &amp; worked but &shy; did not, I'm not entirely sure what's going on internally without auditing the underlying code (for HTMLPurifier), and would likely have to do the same for CKEditor and/or ProcessWire. If you change the field from a WYSIWYG interface to a simple textarea, does it work as expected? If so, you might need a CKEditor plugin for the soft hyphen, but I'm simply guessing. In the one Stack Overflow topic I found, most people actually recommended using <wbr> over a soft hyphen - why do you feel it's "kinda outdated"? With the exception of Internet Explorer 11, it has full browser support, and if it works right now (whereas soft hyphen does not) then that's less time you'd need to worry about it. As for the lack of a hyphen, there might be some CSS solutions there, but I'm unsure how well they'd work out. One last thought: I didn't test this in ProcessWire myself -- are you sure it's not just converting the text of &shy; to \u00ad in the database?

Hello da², I still stand by my comment in that you are in compliance, a warning is not the same as an error, and attempting to circumvent the current processing of text for the sake of clearing a warning may cause more harm than good. That said, this topic came up back in October, and the linked topic should provide you with possible workarounds, if you decide to take them: EDIT: For any modules that output their own HTML (ex: InputfieldText's ___render() method), you'd need to find, and then override the module's own output method to fix; or setup and run all of your generated HTML through a post-processor.

Hey Ryan, Thanks for replying and confirming my assertions above, and also thanks for identifying your intentions of its purpose. That was what I figured it was for (primarily cleaning pasted content from other rich text editors). I could see some end-users copying and pasting from other websites, or even other owned properties of theirs and, if sharing a CSS theme, expecting a similar output. To be frank, I don't even think I would want that to work, but I wanted to test just to be sure how versatile the Pastefilter was, and what its limitations were. As for pattern matching attributes or values, I can't currently imagine a necessity for that particular use-case, and until there is one out there by someone, I don't think there's any need to even consider building it into core. Regardless, I'm pretty stoked for this additional functionality for cleaning pasted content!