Leaderboard

I was glad to see there was interest in the new URL hooks added last week, thanks! There were still a few details to work out, so thought I'd take care of those this week before moving on to other updates, and they are now in 3.0.174. Today I've also updated last week's blog post with the additional info, so that it's all in one place. This will likely be converted over to a dedicated documentation page, but for now, here is what's been added: The post last week introduced you to using named arguments. This week another kind was added, called simple named arguments (click the link for details). The idea is based off an example from another post in these forums by BitPoet. The handling of trailing slashes vs non-trailing slashes was undefined last week. This week it has been defined and is now enforced by ProcessWire. All of the details are here. Pagination was another grey area last week, but no longer. Here are all of the details on how you can utilize pagination in URL/path hooks. In addition, in 3.0.174 URL/path hooks can now have control even after a Page (template file) throws its own 404, whether by wire404() or throw new Wire404Exception(). I found this was necessary because it is possible to enable URL segments for your homepage template. And, depending on your homepage template settings, that means it is possible for the homepage to be the recipient of all URLs that don't match pages. This would leave no opportunity for URL/path hooks to execute. So now ProcessWire gives URL/path hooks another opportunity to run if it matches the URL, even after a 404 is thrown from a Page template file. Beyond the above, there's been a lot of additional optimization and improvement to the hooks system that handles the path/URL hooks, but nothing further that affects its API... just internal improvements. ProcessWire 3.0.174 also adds a feature requested by Adrian, which was to add object return value support for the recently added $pages->findRaw() method. The method by default returns arrays for everything, which can be helpful in making clear you are working with raw data, in cases where it matters. (As opposed to formatted or prepared page data). But if you specify objects=1 in your selector to the method, it will instead return StdClass objects where it previously returned arrays. This makes working with the data more consistent with how you might work with Page object data, even if it is still raw data. Should you be using any findRaw() data for output purposes, you can now also specify entities=1 in your selector to have it automatically entity-encode all string values, or entities=field, replacing "field" with pipe-separated field names you want entity encoded. The following example summarizes all of the recent additions to findRaw, as pretty much everything here was not possible on the first implementation: $items = $pages->findRaw("parent=/blog/posts, fields=title|url, entities=title, objects=1"); foreach($items as $item) { echo "<li><a href='$item->url'>$item->title</a></li>"; } Thanks for reading and have a great weekend!

https://www.tandc.games/ New website for my games design company. We're currently working on Grace Hopper: Bug Rescue about computer science history, check it out and let me know if you have any suggestions for historic characters or topics/hardware. Built with PW, and is heavy built upon my other website https://www.ethicalby.design/ basically taking it as a base and building on it.

Hi everyone! I did not have the time to look deep into it, but looks like version 3.0.173 has made some changes into the handling of hooks. Especially hooks for custom urls, like we do in AppApi. Previously we had to use a little workaround to get it done - we hook into 404 (site not found) exceptions and generate our own response, if the request was made for /api/... The new update seems to add a functionality, where our module can use an url, without doing the 404-hack. But the new functionality seems also to break some of the old functionality. ? So, please wait with the 3.0.173 upgrade! Thank you @csaggo.com and @psy for mentioning it. I will have time to look into it on the weekend - pull requests or hints are very welcome!

BETA: SplashAndGrab https://github.com/madebymats/InputfieldSplashAndGrab This module attaches a search input to selected image fields that lets you search and download images from Unsplash. (Unsplash is a stock photo service where you can download images for free and use as you wish. No strings attached.) You can search by string, colors, orientation/crop and order by relevance or time published I find Unsplash useful both for placeholder images when building sites but also as a time saver for editors if they don’t have any images at hand, just search, download and publish. Thanks to @apeisa for building the FlickrInputField Module and @Robin S for AddImageUrls, took a lot ideas and code from those modules.

Aha! The tut I intend to write will explain what all those options do (although the WordPress tut has some good explanations as well).

Same here! This one. Hehe. Tell me about it!

I didn't, until earlier this week! I managed to get hotreload inside a ProcessWire Process Module that displays a Vue JS App in development mode, running under a different port from ProcessWire! I also threw in live reload in the mix for changes to my .module, .php files, etc. I'll do a writeup when I get some time. FYI, this only worked with vanilla Vue JS. I couldn't make it to work with Nuxt or Gridsome.

cross reference:

Yep, everything I had working with AppApi and REACT/NextJS broke with the PW 3.0.173 upgrade. Downgrading is a short-term option but limits future PW upgrade benefits

I can confirm this issue with the latest dev at time of posting (commit 6146ba4eb1fa3650a43c789a98026d7af4b5e317)

Hi @Sebi kann you confirm that the latest PW (3.0.173) breaks AppApi (404 on the routes) or is it something on my part. EDIT: confirmed it myself, Downgrading to 3.0.172 with no other changes solved the issue Thank you!

Hi! Wanted to know if anyone has a more elaborated guide on how to use Vuejs with Proceswirer for Process/Inputfield modules with hotreload and all the webpack nice thingies ? so that for example, I can view the process/inputfield module in development in the context of the ProcessWire pages/routes.

Seems that things changed slightly ? This worked for me today: Translate file /wire/modules/Inputfield/InputfieldDatetime/types/InputfieldDatetimeText.php Set path: /wire/modules/Jquery/JqueryUI/i18n/jquery.ui.datepicker-de.js Search keys: datetime, date picker, monday, translate, sunday, german

@LostKobraKai Thank you. I will look into the Lister Pro Action. Meanwhile I decided to export the users including their hashed password to csv with // get desired users $array = []; $us = $users->find("roles=frontend"); foreach ($us as $key => $u) { $u->of(false); $array[$key] = ["id" => $u->id, "name" => $u->name, "email" => $u->email, "pass" => $u->pass]; } // write to file $fp = fopen('./inc/users.csv', 'w'); $i = 0; foreach ($array as $fields) { // Add headings to the first line. if($i==0) fputcsv($fp, array_keys($fields), ","); fputcsv($fp, $fields); $i++; } fclose($fp); Now I am looking into a way to import the users in the new PW install via API and in that process bypassing the regular $user->pass method for setting the password. So that I can store the hashed password as is during import. Then I'd only need to copy over the salt from the original PW install and the users should be able to login. But when looking at the ___setPass($value) method in /wire/core/Password.php, I am not sure how to hook into it and make it just save the supplied value. Also, looking at /wire/core/User.php, I don't see how this is connected to the Password class or vice versa.