Leaderboard

All the updates I mentioned last week are committed on the dev branch today, and it's quite a lot of new code and revised code. There's enough here to justify a couple of version bumps, but I'm leaving it at 3.0.185 temporarily because the ProcessWireUpgrade module will see the version change and some people might upgrade automatically. Because there's so much that's been rewritten, refactored, added and changed here, I'd like it to marinate for a week on the dev branch before it triggers any upgrade notifications. Our dev branch tends to be very stable, and this is one week where there's enough new code that I don't want to call it as-stable-as-usual just yet (though it might very well be). In addition, it's also not totally finished as there's still some redundant code to be removed and stuff that needs to be moved around a bit, though everything should be fully functional as-is. I am running it here on the processwire.com site without any issues, so chances are that all is good, but I always like to be cautious. Below is a summary of what's new and changed. It's a bit technical, and there's nothing here that's all that important to know about, but whether you read on or not, just know that the core is getting even better and faster with updates like these. The core PagePaths module has been refactored and has multi-language support. Previously it only worked on single-language sites. Now multi-language sites can take advantage of potentially significant performance improvements offered by this module. This is one module that is not installed by default, but it's definitely worth installing: Modules > Core > PagePaths. The core LanguageSupportPageNames module has been refactored. Assuming I did it well, you shouldn't notice any difference other than that it's faster. For instance, one of the changes is that it drops its old indexes on the pages table and re-creates them in a different way. I discovered some situations where finding pages by multi-language path was resulting in full pages table scans. Using MySQL “explain” statements I found I could prevent that by reversing the order of the columns in the language-specific indexes, preventing the full table scan and making it many times faster. This could make a big difference on large multi-language sites, but is less likely to be noticed on smaller sites. The LanguageSupportPageNames module also gained a new configuration setting that lets you specify what should happen when a page is accessed at a language it's not available in: throw a 404 or redirect to the default language. The core PagePathHistory module has been refactored. It has a powerful new getPathInfo() method, though it's primarily of interest for internal core use. A new PagesRequest class has been added to the core and it can be accessed from $pages->request(). It primarily focuses on one hookable method: $pages->request()->getPage(). The method accepts no arguments but it analyzes the current request, identifies the page to render, and returns it. Previously this logic was in the ProcessPageView module. The benefit of this method is that you can now determine the page to render much earlier, like during the boot process. Previously the current page wasn't identified until after PW booted and the ProcessPageView module loaded. This will enable [for example] a module such as SessionAllow to decide whether or not to allow sessions based on what page was requested. In addition, this method is hookable, so you could have a module that adds its own logic to identify or change the page that should be rendered. A new PagesPathFinder class has been added to the core and can be accessed from $pages->pathFinder(). Like the PagesRequest class, this new class primarily focuses on one method: $pages->pathFinder()->get($path). The given $path can contain any page path, optionally containing language prefix, URL segments, pagination numbers, or even a previously named version of the path. It will find and validate that path and return an array of information about it. PagesPathFinder does its job very quickly. In fact, it's about 10 times faster (in testing/timing locally) than PW could previously identify this information using existing methods. PagesPathFinder will also take advantage of the PagePaths and/or PagePathHistory modules when appropriate, if they are installed. Below is an example of what the return value would be for path /es/hello/bar/baz/page3 where /es/ is the language prefix, /hello/ is the actual page, /bar/baz/ are the URL segments and /page3 is the pagination number segment. It analyzes everything out and returns a 200 "ok" response if the path is good, or in this case, it's returning a redirect because it detected a Spanish URL with English page name and pagination prefix, and it's suggesting a redirect: $info = $pages->pathFinder()->get('/es/hello/bar/baz/page3'); [ 'request' => '/es/hello/bar/baz/page3', // path that was requested 'response' => 301, // one of 200 (ok), 301 (permRedirect), 302 (tempRedirect), 404 (pageNotFound), 414 (pathTooLong) 'type' => 'permRedirect', // ok, permRedirect, tempRedirect, pagePathError, pageNotFound or pathTooLong 'errors' => [], // array of error messages indexed by error name 'redirect' => '/es/hola/bar/baz/pagina3', // suggested path to redirect to, blank otherwise 'page' => [ // info about page that was matched 'id' => 1237, 'parent_id' => 1232, 'templates_id' => 12, 'status' => 1, 'name' => 'hello' ], 'language' => [ 'name' => 'spanish', // name of language detected 'segment' => 'es', // segment prefix in path (if any) 'status' => 1 // language status where 1 is on, 0 is off ], 'parts' => [ // all the parts of the path identified [ 'type' => 'language', 'value' => 'es', 'language' => 'spanish' ], [ 'type' => 'pageName', 'value' => 'hello', 'language' => 'default' ], [ 'type' => 'urlSegment', 'value' => 'bar', 'language' => '' ], [ 'type' => 'urlSegment', 'value' => 'baz', 'language' => '' ], [ 'type' => 'pageNum', 'value' => 'page3', 'language' => 'default' ] ], 'urlSegments' => [ // URL segments identified in order 'bar', 'baz' ], 'urlSegmentStr' => 'bar/baz', // URL segment string 'pageNum' => 3, // requested pagination number 'pageNumPrefix' => 'page', // prefix used in pagination number 'scheme' => 'https', // blank if no scheme required, https or http if one of those is required 'method' => 'pagesRow', // method(s) that were used to find the page ] While you might never need to use this method yourself, ProcessWire now uses it on every request. And now that this logic is isolated from ProcessPageView and has a dedicated $pages API, it's much more open and we can, for example, more easily apply tests to this logic. I've covered a few updates here but there's more if you feel like digging in the commit log https://github.com/processwire/processwire/commits/dev. Thanks for reading and have a great weekend!

There's a propery _pfscore (page finder score) returned from full text searches. You can use that to filter out low scores. For a recent site I appear to have used: foreach($matches as $match){ if($match->_pfscore < 900){ $matches->remove($match); } } but you can fiddle around with that value to suit. Not sure if there's a way of specfying a minimum score in your query.

Behind the scenes, the admin user is a page with the id 41, so you can determine the username by running the following sql query: select `name` from `pages` where `id` = 41; The quickest way to reset the password should be this:

Or do this... Or one of these... (includes the extension @adrian mentioned above)...

Please try to add this extension: https://htmx.org/extensions/ajax-header/ so that Tracy sees the ajax request. BTW - thanks again for your donation to Tracy - always appreciated!

Adapting a post Ryan made in the Repeater Matrix support forum: In /site/templates/admin.php, before the line... require($config->paths->core . "admin.php"); ...add the following... if($page->process == 'ProcessPageEditImageSelect') { // The page ID that is open in Page Edit $edited_page_id = (int) $input->get->edit_page_id; // The page ID that contains the CKEditor field // This is where PW will look for images by default $cke_page_id = (int) $input->get->id; // If the edited page is not the same as the CKEditor page if($edited_page_id && $cke_page_id && $edited_page_id != $cke_page_id) { // Get the CKEditor page $cke_page = $pages->get($cke_page_id); // If the CKEditor page is a particular Repeater field page // Substitute the name of your Repeater template if($cke_page->template == 'repeater_your_repeater_template') { // Set the page ID where you want PW to look for images $input->get->id = $edited_page_id; } } }

Ok, I am getting deeper) I figured out I need to turn off No debug bar in... -> Form Builder Iframe in Tracy's config. That fixed it! And it seems that we do not even need the X-Requested-With: XMLHttpRequest header for that. But I am actually having another issue with my implementation. Which I am not sure sure is Tracy related, but maybe you could help me anyway) I am Initiating a page reload with js (document.location.reload();) after certain data was returned (on successful form submission). Is there a way to pass Tracy debug data in this case to the final page? I already coped temporarily turning the redirect off, but would like to know if I could do it in case that was impossible.

Hey @JohnRodgers have a look at this module: Maybe it's a little bit older but I think, it'll still do its job. Greets, DVJF alias Jens

There's a couple things that made me think this part of the core could be better (and nothing related to middleware). First is that PW didn't originally support multi-language URLs, and so the LanguageSupportPageNames module was built to hook in and add support for that. There are benefits (performance, simplicity, etc.) to having that logic lower-level in the core and part of the same logic that identifies non-multi-language URLs. So that's something I've been interested in for a long time, but it was always more than I wanted to get into. The other thing is that I was working on that SessionAllow module and found it was a real drawback not to be able to know what Page was requested before deciding on things like whether to allow a session or not. Granted, we can still know the request URL before we know the Page, but it just seemed a lot more flexible for the core to know the requested Page much earlier in the boot process. That way, we can do things like configure whether sessions are allowed on a per-template basis, where such an option seems to make the most sense. Another example is 404 pages—maybe we don't need a session on a 404 page. But without knowing whether the URL will resolve to a Page or not, we didn't have that choice. Following these updates, we will. Lastly, I just like to revisit the core logic for things and improve it when/where possible, which helps to keep it fresh on the mind. But I don't like to get into replacing this kind of major core code when it'll soon be merged to the master, as this is the kind of stuff that needs more testing over a longer period of time. So with a comfortably stable master version available right now, it seemed like a good time to work on this.

Looks like someone (apparently a single user) has been going around forums and vulnerability databases posting about a ProcessWire "local file inclusion" vulnerability, claiming that in a specific old version of ProcessWire (2.4.0) simply passing "download" GET attribute to index.php is enough to download any local file on the system, including files that may be outside the ProcessWire installation path. This is not a real ProcessWire vulnerability — this kind of argument has never existed in any version of the system. Simply put the report is either fake, mistake, or there could be some custom-built vulnerable piece of code (or other vulnerable software) on the host resulting in this behaviour. We take such claims seriously, however unlikely they may seem, so just to make sure I've just checked parts of the codebase in both 2.4.0 (where this is supposedly occurring) as well as various later versions, and there's zero evidence to back this claim up. I've also manually tested this on various setups, including a brand new 2.4.0 installation, to no avail. (Note: I wouldn't post about this here unless the original claim was relatively widely spread. Just felt it made sense to clear things up.) --- That being said: as one builds sites using ProcessWire (just like with any other system) they need to be careful not to introduce vulnerabilities of their own. ProcessWire is armed with brilliant tools for preventing common vulnerabilities — the selector engine helps avoid various SQL issues, Sanitizer has many tools for cleaning up dirty data, SessionCSRF makes implementing proper CSRF protection downright trivial, etc. — but it can't protect you automatically from every mistake ? More security tips: https://processwire.com/docs/security/.