Leaderboard

This week I kept working on what's been in progress the last couple of weeks. That wasn't really the plan, as I was hoping to move on to other parts of the core. But I found it a took a lot of time to adjust everything to the new code and classes, and to refactor and remove other chunks of code that could either be simplified or removed. So these last few weeks of updates took a lot more time than I expected, and it's one of those things where once I got into it I felt I had to keep working until it was done as well as it could be. That meant getting pretty deep into some core logic. So in hindsight I'm slightly regretting refactoring so much code without major short-term benefits that can make more interesting reading here. And there are perhaps some short-term drawbacks in potentially introducing new bugs, as goes with any new code. But that's how it is sometimes. The good news is that it's a definite improvement in quality and I have no doubt there will be long term benefits especially in terms of improved performance and maintainability. But in any case, I'm glad to be wrapping up these particular updates so that I can move on to other parts of the core and Pro modules, and hopefully I'll have more interesting stuff to write about next time. One small addition you might find useful in these updates is that you can now identify the closest matching page when a 404 occurs. Maybe you want to provide a hint to users that land on a 404 as to what page they might have been looking for. Now you can do this in your 404 page template file: $p = $pages->request()->getClosestPage(); if($p->id > 1) { echo "<p>Were you looking for <a href='$p->url'>$p->title</a>?</p>"; } Like last week I'm not bumping the dev branch core version just yet because I don't want to trigger any upgrade alerts that might prompt people to upgrade immediately. I'd rather focus more on testing and leave these updates to those that are interested in that testing, helping to track down any issues. Thanks in advance for your help with testing these updates. Likewise, thanks for reading, I hope you have a great weekend!

Now in the module directory: https://processwire.com/modules/process-indie-auth/ IndieAuth lets you sign in to applications using your domain name and grant access to read/write to your site. This module adds IndieAuth support to your ProcessWire site, enabling two main things: Authentication: When you visit a site like indielogin.com and enter your domain name, you will be taken to your ProcessWire admin area to sign in and approve the request. If you approve the request, you will be returned to the site and logged in as your domain name. Authorization: When you visit an application like Quill, it needs to also get your permission to post to your site. You will be taken to your ProcessWire admin area to sign in and approve the request/scopes that the app is requesting (create, update, delete, etc.). If you approve the request, you will be returned to the app, logged in as your domain name, and the app will have an access token for your site. Features Browse the applications you have granted access tokens to. See when each one was granted, last used, and will expire. Revoke any application’s access tokens Set the default expiration period for new access tokens. The initial default is 14 days. Automatically remove expired tokens During authorization, confirm and change the scopes granted to the application. For example, an app may request “create” and “delete” scopes, but you can grant only “create.” During authorization, you can also choose to grant an access token with no expiration Installation Navigate to Modules > New. In the Module Class Name field, enter ProcessIndieAuth Copy the template files from the module’s directory /extras/templates into your site’s /site/templates directory. Verify that the plugin installed pages: IndieAuth Metadata Endpoint Authorization Endpoint Token Endpoint Token Revocation Endpoint IndieAuth page under the admin’s Access menu Look up the user(s) that you want to allow to use IndieAuth and assign them the “indieauth” role Update your home page template to add the link elements inside the <head> element: <?=$modules->get('ProcessIndieAuth')->getLinkElements();?> This should result in three <link> elements in the source HTML: <head> <link rel="indieauth-metadata" href="/indieauth-metadata-endpoint/"> <link rel="authorization_endpoint" href="/authorization-endpoint/"> <link rel="token_endpoint" href="/token-endpoint/"> </head> Sign In To test signing in with IndieAuth, visit indielogin.com and enter your domain name. Follow the prompts to authenticate and you should end up back on indielogin.com with a success message. Sign In and Authorize To authorize an application with IndieAuth, your site will first need a module that uses access tokens. I have a Micropub for ProcessWire module in development that does that. Micropub is a standard that lets you publish to your site using third-party clients. If you’d like to try it out, follow the instructions on GitHub to install it. After installing, visit Quill and enter your domain name. Follow the prompts and note the additional fields for “scope” and “expiration,” since you are authorizing an application to interact with your site. After successfully authorizing, try to post a short note from Quill. Quill should redirect you to the new post if it was successful. For a list of other Micropub clients you can try, see https://indieweb.org/Micropub/Clients. Admin and Options In the admin, you can see which applications you have granted access tokens to. You can see when each token was issued, last accessed, and its expiration. You can also manually revoke a token at any time. Navigate to: Access > IndieAuth. There are a couple options in the admin at: Modules > Configure > ProcessIndieAuth: Default access token lifetime (in seconds): This defaults to 14 days and is what appears in the authorization screenshot above. Automatically remove access tokens after expiration (enabled by default): When enabled, the site checks approximately every six hours and removes expired access tokens. Regardless of whether this option is enabled, the module will reject any application attempting to use an expired access token. Since access tokens cannot (currently) have their expiration extended, I recommend keeping this option enabled so the admin list stays tidy and current. Finally, this module writes some admin logs. Access those at: Setup > Logs > indieauth More About IndieAuth If you’re interested in more details about IndieAuth, I recommend the article “OAuth for the Open Web” by Aaron Parecki (or the video presentation). If you are interested in implementing IndieAuth in your project, see the IndieAuth specification. Originally published at: https://gregorlove.com/2022/07/indieauth-for-processwire-released/ Previously: 2021-10-07: This post was originally about alpha testing the plugin before I submitted it to the modules directory.

Right - as part of my efforts to show off more of the work we've done recently, here's a site we launched earlier this year. On The Record are a not-for-profit that specialise in oral histories and creative media. We've done a few nice projects with them ( A Hackney Autobiography was a lovely project we did with them in our pre PW days). A creative design was very important to them as well as being accessible and usable. There's not too much bespoke backend coding going on. We needed to provide them with a way of easily adding audio and video files but that was mostly done using normal fields and a modified version of Ryan's TextformatterVideoEmbed module adapted for use on plain text fields. Apart from that, it's just the usual supects for extra modules: ProCache LoginPersist and Macrura's ProcessDocumention module which we normally use for provide help pages in the admin area. The front end is pretty much bespoke but with a few components lifted from various places; looks like we used Bootstrap grid for one. It's another site where we used CSS filter properties to apply a consistent look and feel to images the client uploads. I think it looks nice anyway and the client is very happy with it and took to using the PW admin with no problems.

Another approach I use on my local dev environment, for completely unrelated projects on different hosts, is to simply symlink the 'wire' folder. My Setup/Structure: /www <-- my localhost root (I'm using Laragon). /processwire <-- folder dedicated to ProcessWire projects. /wire <-- the ACTUAL location of the wire folder that the symlinks point to. /project_a <-- each separate project (treat this folder as the web root: http://project_a.localhost/ ) /site <-- the project's ProcessWire /site folder /wire <--- this is a SYMLINK to the /www/processwire/wire folder /.htaccess <-- the ProcessWire .htaccess file. /index.php <-- the ProcessWire index.php file. /...etc <-- any other files that you'd put in the web root of a project (robots.txt etc). /project_b <-- same folder/file structure as above When I want to update the ProcessWire version, I just download it and copy the 'wire' folder over into /www/processwire (I actually rename the old folder, copy over the new and check everything works before deleting the old folder). Adding a New Project My process for adding a new project, we'll call it 'project_c', is then: Create the project in the ProcessWire projects folder: /www/processwire/project_c Create a local url for the project (http://project_c.localhost/) and point it to the newly created folder above. In the 'project_c' folder, unpack a copy of ProcessWire (the same version as the current shared wire folder for simplicity). In the browser visit http://project_c.localhost/ and run the installer as usual (& create the DB). Once installed successfully, delete the /www/processwire/project_c/wire folder (or rename it and delete later if it all works ok) and create a symlink to the shared 'wire' folder. The advantage of this for me, is that it does away with the need for naming the site folders 'site-project_a', 'site-project_b' etc.

Great to see those core things evolving. Someone has to look after them. And we all know who that is))

Basically <?php namespace ProcessWire; // create field $field = new Field(); $field->name = 'my_field'; $field->label = 'My Field'; $field->type = 'FieldtypeText'; // save field wire('fields')->save($field); // get field $field = wire('fields')->get('my_field'); // Create fieldgroup $fieldgroup = new Fieldgroup(); // if you want to edit fields in this field group via admin panel, name need to be same with template name $fieldgroup->name = 'my_template'; $fieldgroup->add('title'); $fieldgroup->add('body'); $fieldgroup->add($field); // save fieldgroup wire('fieldgroups')->save($fieldgroup); // get fieldgroup $fieldgroup = wire('fieldgroups')->get('my_template'); // Create template $template = new Template(); $template->name = 'my_template'; $template->label = 'My Template'; $template->fieldgroup = $fieldgroup; // save template wire('templates')->save($template); // get template $template = wire('templates')->get('my_template');

@Clarity @Jonathan Lahijani I pushed a fix, can u update next branch and try ? Entering language based data, Exporting and importing Mystique field data Video result Ekran Kaydı 2021-10-08 22.46.51.mov

Seems feasible. Depending on how it's done, just switching $pages->find() to $pages->findMany() can help a lot (assuming it's a relatively new PW). Recently worked on a site with ~700k pages, and making this change to SchedulePages helped speed things up considerably.

I have many web projects using mystique fields, i didn't see an error like this. You can make a try with clean processwire install, after that if this error continue for your create an issue on github repo.

See the attachment for the job posting. Contact information is in the posting. 2021-10 Lead Web Programmer.pdf

// requeire https://processwire.com/modules/file-validator-svg-sanitizer/ and $svgSanitizer = $this->wire()->modules->get('FileValidatorSvgSanitizer')->getSvgSanitizer(); $svgSanitizer->minify(true); $svgSanitizer->removeXMLTag(true); $data->setArray([ 'inline_svg' => $svgSanitizer->sanitize($this->wire()->files->fileGetContents($category->get('svg')->filename)), ]);

Hi, i think you should have a closer look at how pw works as i would strlongly advise you not to use aliases (slugs) in the nav as they may change nor to use templates of course have a look at a simple, very simple nav <!-- link to the home page if your website is not multilingual you can simply use <a href="/"> --> <a href="<?php echo $pages->get(1)->url; ?>"><?php echo $pages->get(1)->title; ?></a> <!-- and then a simple list of the other pages of course, you can exclude some pages ids and put the wole stuff inside an ul or whatever you want going a little further, i let you guess how to deal with sub menu, easy as soon as you've understood how it works --> <?php $pgs = $pages->get(1)->children; foreach ( $pgs as $p ): $activ = $page->id == $p->id ? ' class="active"' : ''; ?> <a href="<?php echo $p->url; ?>"<?php echo $activ; ?>><?php echo $p->title; ?></a> <?php endforeach; ?> you could also have a look at the menu modules and either use one or understand how they work to make your own https://processwire.com/modules/process-menu-builder/ or https://processwire.com/modules/markup-menu/ they offer different way of building menu and can be a good starting point for your own hope it helps have a nice day

I think it is not good if admin's path is known to hacker, since they potentially can brute-force superusers' accounts by this URL and eventually hack someone's account, receiving the access to the Admin Panel. The hackers may know which CMS the site uses from the site https://whatcms.org/, and if they know a thing or two about ProcessWire, they will attack /processwire path first.

Yes, I think this is exactly what I will do. Like you say, it's easy to do so might as well. As a simple addition to @FireWires great answer: Don't forget about the relatively new url hooks! https://processwire.com/blog/posts/pw-3.0.173/ You don't need a dedicated page then (which means that you also do not need to hide that page from the tree via hooks)

Thanks a lot for such a detailed reply, it is most useful. ? I always leave the login as /processwire but then they tend to be brochureware type sites so not exactly highly sensitive. Yes, I think this is exactly what I will do. Like you say, it's easy to do so might as well.

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 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.

Depending on how complex your needs are and the project's budget, there's also the Login Register Pro (paid for) module https://processwire.com/store/login-register-pro/.