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!

how.abt u use $cache 2 do jus do it. 1once per hour ? echo $cache->get('topic-count', 3600, function() use($topics) { $str = ''; $strategy = pages()->get("template=genre, name=strategy"); foreach($topics as $topic) { $count = pages()->count("template=game, genre=$strategy, topic=$topic"); $str .= "<li>$topic->title: $count games</li>"; } return $str; }); also.2 make faster u better should uses "id" not name, so "topics" no 'topics.name' and "genre" not genre.name etc. othrwis pw have to look those up for u (?) every time of foreach @rjgamer

JIT for Tailwind was just announced. It's looks really great. I'm still on the sidelines with Tailwind, but I do see myself using it in the near future. @kongondo when HeadlessUI has components in Alpine that are fully fleshed out, that's when I think I'll make the switch. While the Creative Tim components look good, I'd rather wait for something that's from the Tailwind creators and more comprehensive.

I figured out the problem. The hosting control panel said that PHP 7.4 was installed but it was actually only supplying 5.4. I got that fixed and the module works now.

It is done. I have found the error. Version 1.1.5, which I just released, fixes the bug and makes AppApi fully compatible with ProcessWire versions >= 1.0.173 again. For those interested in the details: It was just a tiny little thing that caused the module to no longer be able to find out if an api url was requested. This is what the code for it looked like: protected function checkIfApiRequest() { $url = $this->sanitizer->url($this->input->url); // support / in endpoint url: $endpoint = str_replace('/', "\/", $this->endpoint); $regex = '/^\/' . $endpoint . '\/?.*/m'; preg_match($regex, $url, $matches); return !!$matches; } However, in ProcessWire versions >= 1.0.173, $this->input->url (or wire('input')->url) now no longer contains the requested URL (e.g. "/api/page/"), but already the URL of the 404 error page "/http404/". Thus, the module could no longer determine whether it should handle the request or not. But the solution to the problem was easier than I thought. $_SERVER['REQUEST_URI'] still contains the correct value. So we use that now for this check. And because this would have worked before, we don't need to worry about AppApi not working with older ProcessWire versions now. The fixed version simply looks like this: protected function checkIfApiRequest() { $url = $this->sanitizer->url($_SERVER['REQUEST_URI']); // support / in endpoint url: $endpoint = str_replace('/', "\/", $this->endpoint); $regex = '/^\/' . $endpoint . '\/?.*/m'; preg_match($regex, $url, $matches); return !!$matches; } Finally, thank you again for your reports. And I hope that you can now run your apis with the latest ProcessWire versions again. Thank you for using AppApi! ?

Hey kaz! This is just a forum policy: the Modules/Plugins area is reserved for support threads of existing modules, one per module. If a question is about an existing module, feel free to post it in the applicable thread. You can find a link ti the thread from the modules directory entry for that particular module. If its not (like this thread here, which is a general question about "which module to use") it's best suited for the general support area. Hope this clarifids things a bit ?

The thing to remember is that this setting is called the "Formatted value", i.e. the value when output formatting is on. When output formatting is off the value of an image field is always a WireArray. And in your code, you specifically turn output formatting off before you work with the field (as you must). If you treat the image field value as an array I think it will work as expected. Something like: $page->of(false); $page->photo->removeAll(); $page->photo->add('https://example.com/img.jpg'); $page->save(); $image = $page->photo->last(); $image->textfield = 'Some text'; $page->save();

I use a modified excerpt from @Robin S's module to add an image from a url like so: $field_value = $p->getUnformatted( $yourField->name ); if ( $yourField->maxFiles == 1 && count( $field_value ) ) $field_value->removeAll(); $pageimage = new Pageimage( $field_value, $url ); $field_value->add( $pageimage );

For pages not using the title field (which you can achieve with: Setup > fields > title > advanced tab > turn off global flag), you can do a couple of modifications: Do this commenting out in importPage function: /*if(!$page->name) { $this->error("Unable to import page because it has no required 'title' field or it is blank."); return false; }*/ Then in importPageValue you can construct a naming scheme or just use the id (after the else statement): $page->set($name, $value); $page->name = $page->id;