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!

Pastefilter: For someone currently testing, could you see what the difference in the Pastefilter is for a[href|id], a[target=_blank] and a[href|id|target=_blank], if any? It seems Ryan split any assignments to their own entry, even though they merge, so I was just curious if there was a reason for that, other than potentially simplified logic/understanding. Not that I currently have a reason to do this, but what if there was a need to whitelist a certain range of classes (attributes; perhaps data-* attributes)? Similar to allowing the pasting of fontawesome content? I'm thinking there's no REGEX or glob matching for attributes and associated values (ex: i[class=fa*] which should cover i.far.fa-horse, i.fas.fa-horse, etc.). Tip on Performance of Plugins: Although it makes complete sense, I might not've thought to check that. I very much appreciate the tip about that, and the "advlist" plugin, specifically! Thanks! The amount of work on documenting its behavior is extremely welcomed - thank you so much, Ryan! EDIT: Pastefilter -- I tested... It appears as though there's a specific distinction when applying value matching as opposed to simple attribute allowance. If providing a match to an attribute's value, it must (currently, at least) have its own unique entry in the list. It cannot be merged with the simpler attribute entry that allows any value. In my testing when I merged the entries together (ex: a[href|id|target=_blank]) only the matching attribute entry was allowed and retained during paste (target=_blank).

Hello Stephan! Hopefully you've scoured the forums and found similarly posed questions by now, but just in case you haven't - ProcessWire is, at its core, a solution for a CMS - a content management system. ProcessWire simply takes that concept a bit further by allowing those who use it to custom tailor the system itself. So with that very short explanation, a Content Management System is something that manages content. This means that once you've come up with a visual template, theme, or whatever you'd want to call it, the system itself is what manages everything from that point onward. Going back and forth from a development tool and using it as your page editor, and hoping that the CMS you choose will simply ingest that - if I'm understanding your use case correctly here - isn't really something that many systems can take advantage of. Theoretically I suppose that it could be used to do it, but it's a lot of work to get it to a point to where it won't realistically even be used to manage things on the site. Using any CMS for this scenario seems like overkill, where the primary content is managed by a visual HTML editor. If it's logical to you, I can't say it's wrong. I will say that it's unique! It's also likely not the best option as: You're relying on your visual HTML editor tool (Pinegrow) to produce proper HTML/CSS/JS that is accessible, and without errors -- and that will always work with whatever main template you intend to embed it into You're installing a PHP/MySQL tool which, other than perhaps for page and navigation management, isn't really being used for anything else, and the powerful functionality found elsewhere in it could not be properly used (ex: search). I think, using the scenario you've provided, the simplest way would be via a PHP include. It's hard for me to picture it all as I'd think if you went this route, it'd almost make more sense to simply manage everything within Pinegrow and just upload all changes manually. I haven't looked at it closely enough, but I think you can manage a navigational structure within Pinegrow, it's just a bit more work. It could be a problem. It all depends on how you create the pages in both systems. If you're not particularly careful with it though, then my answer here would be, "Yes, it could be a problem." Absolute vs relative links would depend on your naming conventions, templating, and internal page creation within PW and Pinegrow. What you could do is use Pinegrow to manage the website in its entirety, as you seem more familiar with that as a tool. Study up on ProcessWire and how it works (and/or other CMS/CMFs to see what might fit your ability and effort the best - flat file-based CMSs might work better for you) - and then slowly convert it to being managed by a CMS instead of Pinegrow.

Unfortunately I don't know anything about OVH. That knowledge might be needed here... If I can reach 'https://auth.giobby.com' in a web browser (GET request) without error, and you're saying that Postman works - then I would have to think everything is configured properly on the server that is handling the authentication portion of your server/code. Considering that, I'd be focusing on playwood.it to see if/why there are issues from there. You could enable debugging in your cURL call: curl_setopt($ch, CURLOPT_VERBOSE, 1); If there's an error, you can review that from your unused variable ($error), and/or check your server/php error logs. From using your code above, however, I was able to get a successfully retrieved value for access_token on my local machine's development/test server.

It seems like you could take advantage of the part of the module's documentation that I linked to above, something like the following: <?php namespace ProcessWire; $searchEngine = $modules->get('SearchEngine'); ... <head> <?= $searchEngine->renderStyles() ?> <?= $searchEngine->renderScripts() ?> </head> <body> <?php echo $searchEngine->renderForm(); // This assumes your search form uses GET, and a field named 'q' if ($q = $sanitizer->selectorValue($input->get->q)) { // Modify your value of the search query ($q) here... // ... // This finds pages matching the query string and returns them as a PageArray: $results = $pages->find('search_index%=' . $q . ', limit=25'); // Render results and pager with PageArray::render() and PageArray::renderPager(): echo $results->render(); // PageArray::render() echo $results->renderPager(); // PageArray::renderPager() // ... or you iterate over the results and render them manually: // echo "<ul>"; // foreach ($results as $result) { // echo "<li><a href='{$result->url}'>{$result->title}</a></li>"; // } // echo "</ul>"; } ?> The biggest benefit to the SearchEngine module is its creation of the (default) `search_index` field. You can query against that field just like any other field within ProcessWire. Rendering the form and search results are just additional benefits.

This might also be able to do what you're looking to do (if you want something out-of-the-box)? It's a commercial module. kongodongo's Dynamic Selects.

Just issued a simple GET request to the provided domain and it redirected (without error) to what I suspect is an expected subfolder. So...either it's working as expected now, it's an issue with your network/computer (and is working), or perhaps you're not taking into consideration URL forwarding from rewrite rules (whereas Postman likely is)?

Hi Clarity, Can you clarify what you mean by, "modify the query during search," perhaps with an example of what you are looking for? SearchEngine does provide the ability for you to not use its default ProcessWire searches, and instead simply prepare the index and form/results for you, so that you can form the query manually on your own depending on your own needs, as shown in the module page's documentation. Is that what you mean? If not, an example would be great. 🙂 Some of adrian's examples within this topic may be of use too.

This could possibly become a course all on its own, but there are often questions on how to manage navigational structures (header/footer/on-page) in ProcessWire. Covering how to (try to) plan around it, either based on the layout design, or based on the architectural design (or the client need?) are all potential topics. Sites with simple structures (and few templates) are usually fairly easy, but if you were to design a website for a university that holds many different departments all with unique needs and content, things can get quite complicated; often times there is the primary navigation, a sub-navigation (that may break into child-navigations per department), and custom footer navigation areas per section! If aimed at beginners, something that should likely be covered early on is templates/themes and ProcessWire's Site Profiles, and how unlike other solutions, downloadable site profiles contain not only the layout and design, but also the underlying architecture and fieldtypes, so switching templates is not (currently) a thing with ProcessWire. (We'd need something like WordPress' various theme builders [ex: Divi] where it's a theme framework, so the framework is the profile, and themes/templates/styles could be swapped within the framework...we just don't have that [yet?] for ProcessWire.) ...oh, and also that files and images are associated to the pages they were uploaded to (instead of a centralized media manager, unless one is setup [through a page] in your magazine website example). Also of note, and this took me awhile too: It's "ProcessWire", not "Processwire". 😅 I'd probably sign up just because I enjoy taking courses. You can always learn something new. Video courses are a lot of work (to keep updated) so I wish you the best of luck on this!

After adding my larger RepeaterMatrix field to the indexed_fields, on my first page save test, I seem to be running into a warning at line 315 of /lib/Indexer.php, "foreach() argument must be of type array|object, null given". I'm not sure why it's detecting the value as null... I'm not sure what I'm doing wrong here. Any thoughts? For reference, the snippet of code for this method is below: <?php protected function ___getRepeatableIndexValue(\Processwire\Page $page, \ProcessWire\Field $field, array $indexed_fields = [], string $prefix = ''): array { $index = []; $index_num = 0; $prefixes = $this->getOptions()['prefixes']; foreach ($page->get($field->name) as $child) { At this moment within the loop, the value of the referenced parameters are: $page = \ProcessWire\RepeaterMatrixPage ... it's forPage attribute is null (perhaps that's why?) but its forField value is my primary repeater field: $content_body $field = \ProcessWire\RepeaterField ... this field, `faqs` is itself a repeater (not matrix) field, which contains a combo field (faq), which has attribute names "question" (text), and "answer" (CKEditor) I believe I have all relevant fields added to the indexed fields selection for SearchEngine within this context: content_body, faqs, and faq. Does SearchEngine support RepeaterMatrix (and/or Repeater) fields with multiple levels of depth? ADDENDUM: I just noticed that on this particular page I'm saving (as a test with these fields added), the RepeaterMatrix doesn't allow the use of faqs (it's a template-based override), nor are there any faqs in the content of the page.

Hi teppo, although I believe this request may be more related to the core module (SearchEngine), I'm thinking that the question might belong here. Apologies if that's confusing! First off - in my limited testing, for files that contain properly stored textual data, this has worked as great as can be expected (based on the capability of the vendor classes). Thank you! My thought here, however, is that if a search result was a hit due to it being a match to contents of a file, the expectation would likely be that the file would end up getting listed as a search result (link). Currently due to how SearchEngine (and ultimately ProcessWire) works, the resultant link is for the page that a file resides on. Since there may be circumstances where many multiples of files exist on a page, or are somewhat hidden, would it be possible to link directly to the matched file instead of the owning page? Random thoughts on this, not sure if it's on the right path or not...: SearchEngineFileIndexer has a configurable option to create separate (database level) index_field entry (or custom-named) field entries specific to the files/images rather than the page (or both, or only the page [default]), and similarly to SearchEngine, what to use as the result_summary_field. This would likely require an alteration to the schema of the index_field from the SearchEngine module, such as, if a file/image, its a column for its path (and if no path, we know it's not a file/image but a standard page). SearchEngine would then, if detecting the extra field in the database, optionally provide a direct link to the file instead of the owning page's URL. Similarly, it may (in certain places) pass along an is_file attribute since I don't know if AJAX-based searches for auto-suggest might want file matching results to show up in all situations (and that could be one way for the developer to prevent it).