BrendonKoz

I figured that was what you were thinking of too while you were giving that answer; in the spur-of-the-moment I would've probably answered the same way. The dependencies are included in the project though and don't (currently?) require a composer install, so you're not entirely wrong either (depending on perspective). Not that it matters, but I think Ryan came from previously using MODx, not Drupal. I don't want to cheat my memory recall, so I'm not going to look it up! I could very well be wrong there too. ? Considering the last-minute changes for setup with your recording, I'd say the end result was spectacular! ...and yes, if you plan to record, using a placeholder where you expect your overlay video will be is what I didn't put into words, but was hoping you'd get out of what I said (somehow?). Thank you for all of the work you put into that. It was well-thought out and well-presented. I wouldn't have thought to use Git to jump around to speed things up during a live coding session; that was a great trick.

During the showcase of Latte, you mentioned VSCode doesn't support Latte colorization. It might now. ? https://marketplace.visualstudio.com/items?itemName=Kasik96.latte I don't use Latte so I couldn't test it, but the star rating looks good. Out of the entirety of the video, the only tiny issue was the one slide where your live video overlay was covering up the demonstration of accessing fields via code (page | template | fields). It was shown later so it was still covered - I'm being very critical here, which means overall it was very well done for a live-code recording! Thank you for sharing!

Thanks for all of the work, Ryan! I hope you enjoy your travels!

I just started thinking about OEmbeds (PW example 1, example 2) and how best to style them so that they appear responsively. Unfortunately, since there are so many various types of embeds, I can't really think of how best to responsively style them in a generalized way, if it's even possible at all. At the moment I'm only using Neue Rituale's fieldtype, if it matters, and thus far only embedding YouTube videos. By default, their embed/render size is quite small. I was able to successfully make them responsive using a little CSS trickery so that it retains its original proportional ratio and fills whatever container space is available to it. I'll likely add in a max-width at some point. However, using a similar technique on an embed that is intended to be tall/thin-width would be unlikely to work out quite as well. Has anyone attempted this feat successfully? For sharing purposes, here is the solution I'm currently using to make the oembed responsive: PW Template: <div class="oembed" style="--aspect-ratio: <?= $page->oembed->width ?>/<?= $page->oembed->height ?>;"> <?= $page->oembed ?> </div> Vanilla CSS (framework agnostic): /* https://css-tricks.com/responsive-iframes/ */ .oembed[style*="--aspect-ratio"] > :first-child { width: 100%; } .oembed[style*="--aspect-ratio"] > img { height: auto; } .oembed[style*="--aspect-ratio"] { position: relative; } .oembed[style*="--aspect-ratio"]::before { content: ""; display: block; padding-bottom: calc(100% / (var(--aspect-ratio))); } .oembed[style*="--aspect-ratio"] > :first-child { position: absolute; top: 0; left: 0; height: 100%; }

Since bernhard didn't clarify, I think he's referring to ProcessWire logs, not system or server logs. My host handles rotation of server log files, but not log files generated by scripts installed by me; does yours (that'd be both neat and scary!)? So, I believe the maintenance being discussed here are the log files found in site/assets/logs/*...? Thus far: deploy and forget, but now I'm going to have to look!!! I'd personally be fine with keeping logs to a maximum number of days old. If I wasn't around or didn't check on something more than 30 days prior it's unlikely I'd be interested in it - though that's just me.

Maybe another ProcessWire.rocks video soon? ?

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.