Leaderboard

This week in the blog we’ll look at the new WireSitemapXML module, a new WireNumberTools core class, and a new ability for Fieldtype modules to specify useful ready-to-use configurations when creating new fields— https://processwire.com/blog/posts/pw-3.0.213/

Just for fun, I asked....

This week we have a new core version available on the dev branch. Relative to the previous version, 3.0.212 contains 32 commits, 16 issue fixes and 3 PRs. Here's a list of what's been added: Improvements were made to InputfieldImage so that you can now add your own image actions with hooks. More details in this post and ProcessWire Weekly #455. Significant refactoring and improvements were made to the ProcessPageEditLink module. One of the most notable is that it now will retain HTML class attributes on links, even if not specifically configured with the ProcessPageEditLink module. This is useful if you've added custom classes for links in TinyMCE or CKEditor, but haven't also added them to the ProcessPageEditLink module configuration. Improvements were made to Text fields so that HTML Entity Encoder is now automatically added. This was covered in detail in last week's post and in ProcessWire Weekly #457. InputfieldEmail has been updated with optional support for IDN emails and UTF-8 local-part emails, per request. Two new $sanitizer methods have been added: htmlClass() and htmlClasses(). These sanitize HTML class attributes, and it's part of what enables us to support the custom class attribute support added in the ProcessPageEditLink updates mentioned above. Added feature request #480 to support configurable file extensions for translatable files (beyond .php, .module and .inc). Added a new uploadName() method/property to Pagefile/Pageimage objects that returns the original unsanitized filename as it was uploaded. Applies only to files uploaded since this feature was added. Be aware the filename is unsanitized so be careful with it. This was to partially answer feature request #56 and this solution was suggested by Bernhard Baumrock. Demonstrating the above, InputfieldFile now shows this original filename if you hover the file icon, and InputfieldImage shows it if you hover the current filename. HTTP requests that contain an accidental double slash in the URL now redirect rather than render the page. The PagesParents class was refactored so that it is now a lot faster in saving its data to the pages_parents table. This is very noticeable if you have a site with more than million pages when changing the parent of existing pages, especially those having children. Previously there was a [potentially very] long delay at large scale, now it is instant. More details on these updates, and additional updates can also be found in ProcessWire Weekly #455, #456 and #457. Thanks for reading and have a great weekend!

If accessibility and avoiding lawsuits matters, I'd avoid going that route. I spoke with a developer friend recently whose client got hit with an accessibility lawsuit. They then had a special accessibility firm audit and maintain the website. Sometime afterwards they got hit with 2 more accessibility lawsuits, although they were thrown out. This might be mainly a US phenomenon however... gotta keep those lawyers busy! UIkit pushed a big update today that (finally) addresses a lot of accessibility issues.

Two years ago I have been working on two magazines. Both share a one instance of Processwire. I had to programme my own domain based queries. There are articles, categories, featured articles cotegory dependent (and time dependent) and also some scheduleable ads places. https://motormix.cz/ https://ceskeokruhy.cz/ Articles can be shown on both sites.

Disable them in /site/config.php.

In site/config.php: $config->useMarkupRegions = false;

Thank you Bernhard, good thinking/ideas there! I did indeed not think of url segments so far, I'll give it a try. With some js sprinkled on top this looks like a nice filter-y solution! Wrt to SEO I'll talk to my people but even if it's problematic that should be easy to fix. Thanks again!

@Sonia Margollé have you seen RockFrontend? It's zero-setup and comes with livereloading both in the backend and frontend. There's also a tailwind starter profile for it. If you find there's something missing let me know and I can see if we can add it.

@Robin S Brilliant! I don't know why I didn't think of that... Thanks!

In executeFoo() you would check the URL segments and do different things accordingly. In executeFoo() $input->urlSegment1 is "foo".

I made a new issue that is more specific. The issue is not limited to superuser. It is more specific in that the trashable() method is calling deleteable() which checks if page is the current page. https://github.com/processwire/processwire-issues/issues/1693 I think that trashable() should not be checking if page is the current page.

Hi @heldercervantes . Here are a few projects I've done, both previously done on WP. The first one is smaller 45k pages, the second one already has 484k pages. https://obukhiv.info/ https://socportal.info/

UPDATE: I noticed I can trash these pages through the api as long as do it from other pages. In other words, it is impossible to trash the current page. I found this github issue where someone pointed out that the behavior changed in this commit to not allow current page to be deleted. This only happens on PW installs that happened after a hard-coded date, so maybe why not many people run into this? I didn't see behavior (current page cannot be deleted) documented in the $pages or $page api. In the code of the commit, there are clear error messages returned. Here is the message for trying to delete the current page: "it is the current page being viewed, try \$pages->trash() instead"; But that message does not show in my case. Also, I'm not trying to DELETE the page, but TRASH it. I tried using $pages->trash($page) instead of $page->trash() but still I get the same error. This seems like it should be a common behavior...have a Trash button on the edit page for some resource, that posts back to the page and the page is trashed, then redirecting to a different page. The Admin dashboard operates this way to trash pages. What am I missing?

It's not exactly a magazine but I did write up a move we did for a site from WP to PW: It has lots of tagging and authors and and so on. And that write up has some handy before and after metrics in which might help you convince them...

Thank you very much! I have been using ProcessWire for quite a bit so I should have known. I have enabled access for padloper template and it's children and it works.

This will be great for everybody using RockFrontend + LATTE. Thank you for your work and that update!! ? But there is still a small step missing/not working. I've added the explanation to the issue with screenshots demonstrating the problem. Would be great if you could take a look at that @ryan so that we can not only tick that request as completed but we can also actually use it to directly translate LATTE files in ProcessWire and we don't need the workaround any more ?