Leaderboard

Hello friends! I have another module for you, which will make your daily work as a Processwire developer easier. Introducing: AppApi This module helps you to create api-endpoints, to which an app or an external service can connect to. Features Simple routing definition Authentication - Three different authentication-mechanisms are ready to use. Access-management via UI Multiple different applications with unique access-rights and authentication-mechanisms can be defined The documentation has become quite extensive, so have a look at the Github repository for details: Installation Defining Applications Api-Keys PHP-Session (Recommended for on-site usage) Single JWT (Recommended for external server-calls) Double JWT (Recommended for apps) Creating Endpoints Output Formatting Error Handling Example: Listing Users Example: Universal Twack Api Routes Page Handlers File Handlers A special thanks goes to Thomas Aull , whose module RestApi was the starting point to this project. This module is not meant to replace this module because it does a great job. But if you want to connect and manage multiple apps or need other authentication methods, this module might help you. I am already very curious about your feedback and would be glad if the module helps you a little bit.

Page Reference Default Value Most ProcessWire core inputfield types that can be used with a Page Reference field support a "Default value" setting. This module extends support for default values to the following core inputfield types: Page List Select Page List Select Multiple Page Autocomplete (single and multiple) Seeing as these inputfield types only support the selection of pages a Page List Select / Page List Select Multiple is used for defining the default value instead of the Text / Textarea field used by the core for other inputfield types. This makes defining a default value a bit more user-friendly. Note that as per the core "Default value" setting, the Page Reference field must be set to "required" in order for the default value to be used. Screenshot https://github.com/Toutouwai/PageReferenceDefaultValue https://modules.processwire.com/modules/page-reference-default-value/

Greetings from the sunny covid hotspot state of Georgia, where we haven’t left the house since March. And now getting ready for the kids to start a new school year from home with virtual learning. Everyone delivers everything now, so there’s no need to go out to a grocery store anymore (or go anywhere). I live about a mile from the CDC, so our school district has more kids with parents working at the CDC than any other. That gives me some comfort, knowing that I won’t be sending my kids back to school until the experts at the CDC are willing to; when it’s really and truly safe. Though I don’t think it’s going to be safe for a long, long time. The US is a rudderless ship right now, so we just have to ride it out. Thankfully, we’re all staying safe and keeping busy. The kids are building houses in Roblox (an online game addiction they have), we’ve converted our yard to be a summer camp, and converted the basement to be a gym, while we clear more space to start building out a massive N-scale train set—my 3 locomotives still work perfectly, even after 35 years of storage. And I’ve been learning how to manage chlorine and PH in an inflatable kids pool that keeps the family cool in the hot weather. The kids miss school and other activities, my wife misses being at her office and people she works with, and we all miss our friends and family, but it’s the way things are now, and I’m just grateful to have my immediate family home and safe; and in place where we can ride out the storm. I’m also really glad that I can work on the ProcessWire core and modules for pretty much the entire work day, and enjoying coding as much as I ever have; feeling great about where ProcessWire is and where it’s going, thanks to all of you. I’ve been working on the latest ProCache version the entire week, so not many core updates to report today other than some new hooks added to the Pages class (they are hooks that the new ProCache can use as well). I’d hoped to have this version of ProCache finished by now, but I keep finding more stuff to improve, so decided give it another 2 days of work and testing, and if all looks good, it’ll be ready to release, which will be next week. This version is essentially a major refactor, where just about every line of code has been revisited in some form or another. But if you are already a ProCache user, you’ll also find it very familiar. While I don’t have it posted for download today, below is a brief look at what’s new. Completely new .htaccess rules (v2) that take up a lot less space, especially when using multiple hosts, schemes or extensions. Ability to choose .htaccess version (v1 or v2). ProCache now creates an example .htaccess-procache file that you can rename and use or copy/paste from. ProCache now has a built-in URL testing tool where you can compare the non-cached vs. cached render times. New setting to specify how ProCache delivered URLs should respond to trailing vs. non-trailing slashes in URL. Significant refactor that separates all ProCache functions into separate dedicated classes. Improved custom lifespan settings with predefined template lines. Improved behavior settings with predefined template lines and simpler letter (rather than number) based definitions. Ability to specify predefined cache clearing behaviors, specific pages to clear, or page matching selectors, from within the ProCache admin tool. New predefined cache clearing behavior: Reset cache for family of saved page (parents, siblings, children, grandchildren, and all within). New predefined cache clearing behavior: Reset cache for pages that reference saved page (via Page references). New versions of SCSS and LESS compilers. ProCache is completely ProcessWire 3.x native now (previous versions still supported PW 2.x even if 3.x was recommended). Numerous other improvements, fixes and optimizations throughout. I’ve previously mentioned a built-in crawler in ProCache. That part has been moved to a separate module called ProCacheCrawler and will be released a little later in the ProCache board. It was taking a little too much time to develop, so I didn’t want to hold up the rest of ProCache while I developed that. When installed, ProCache communicates with the crawler, identifying and adding URLs to a queue to be crawled and primed for the cache. What it does is pretty cool already, but it needs more time to develop. It’s also something that depends on being run regularly at intervals (like with CRON) so it’s a little bit of a different setup process than the rest of ProCache, which is another reason why I thought I’d develop is as a separate module. I’ll be working more on finishing development of the crawler later in the year, after the next master version of ProcessWire core is released. Next week I'll have the new ProCache version ready for download as well as a new core version on the development branch. It will focus mostly on fixes for issue reports as we continue working towards the next master version. Thanks for reading and have a great weekend!

I have exciting news for you: ? For the release of my module AppApi I have now also finished the section about the Ajax output of Twack. Twack and AppApi work together perfectly. The routing and authentication is done by AppApi. Twack can also render JSON instead of HTML-views. Here you can find out more about routing with AppApi: https://github.com/Sebiworld/AppApi#example-universal-twack-api And here is the description of the Ajax (JSON) output of Twack components https://github.com/Sebiworld/Twack#ajax-output

@r.loeber, I'm not sure why the "Default value" option that is available for most Page Reference inputfield types isn't available for Page List Select, Page List Select Multiple and Page Autocomplete, but I made a module that extends default value support to these inputfields:

Hi Dragan, thanks for the advice: Actually, the rewrite base was not the problem - but the #Options +FollowSymLinks #Options +SymLinksifOwnerMatch was. I found this error by checking the error logs. Now it works fine!

Hi @Gideon So. Thanks for chiming in. I see we posted at the same time. Please let me state that this is incorrect. @spercy16's function is a recursive function ? It can be called inside itself. The code works just fine as it is (I tested it) ?

Hi @spercy16, Your snippet is working just fine for me. I am not sure what you mean by not working in my child pages but I think the reason is access issues. The following will not naturally show up in page finds: Unpublished pages Pages the user has no access to Hidden pages If your pages (including child ones) fall into any of those categories, they will not show up. However, if you need them to, you can override access control behaviours. For something like a menu, that may not always be what you want. For instance, if a page is unpublished, you want it that way for a reason. Please have a look at the docs (link below) for how you can use (for example, $pages->get('/')->children('include=unpublished')) overrides in your selectors. https://processwire.com/docs/selectors/#access_control Since you are new to ProcessWire, please note that overriding access controls using 'include=all' for the children of Home ('/') means you are asking ProcessWire to return all pages on the site, including admin pages, roles, permissions, etc, clearly not what you want. Additionally, calling $pages->get('/')->children without any limits, [e.g. $pages->get('/')->children('limit=50'))] can potentially lead to the retrieval of lots of pages (assuming you have a big site). A quick by the way, although this: foreach ($children as $page) does not affect the working of the function, since the $page variable is out of scope inside a function, it's just good to know that if used outside, it would have side-effects, i.e. overwriting the current page (variable). Maybe you knew this already. Otherwise, conventionally, some people go for $children as $child or $children as $c or $children as ....whatever, for consistency (and clarity) of use in and out of functions ?. Welcome to ProcessWire and the forums ?

Since it's featured in ProcessWire Weekly #310, now is the time to make it official: Here is Twack! I really like the following introduction from ProcessWire Weekly, so I hope it is ok if I use it here, too. Look at the project's README for more details! Twack is a new — or rather newish — third party module for ProcessWire that provides support for reusable components in an Angular-inspired way. Twack is implemented as an installable module, and a collection of helper and base classes. Key concepts introduced by this module are: Components, which have separate views and controllers. Views are simple PHP files that handle the output for the component, whereas controllers extend the TwackComponent base class and provide additional data handling capabilities. Services, which are singletons that provide a shared service where components can request data. The README for Twack uses a NewsService, which returns data related to news items, as an example of a service. Twack components are designed for reusability and encapsulating a set of features for easy maintainability, can handle hierarchical or recursive use (child components), and are simple to integrate with an existing site — even when said site wasn't originally developed with Twack. A very basic Twack component view could look something like this: <?php namespace ProcessWire; ?> <h1>Hello World!</h1> And here's how you could render it via the API: <?php namespace Processwire; $twack = $modules->get('Twack'); $hello = $twack->getNewComponent('HelloWorld'); ?> <html> <head> <title>Hello World</title> </head> <body> <?= $hello->render() ?> </body> </html> Now, just to add a bit more context, here's a simple component controller: <?php namespace ProcessWire; class HelloWorld extends TwackComponent { public function __construct($args) { parent::__construct($args); $this->title = 'Hello World!'; if(isset($args['title'])) { $this->title = $args['title']; } } } As you can see, there's not a whole lot new stuff to learn here if you'd like to give Twack a try in one of your projects. The Twack README provides a really informative and easy to follow introduction to all the key concepts (as well as some additional examples) so be sure to check that out before getting started. Twack is in development for several years and I use it for every new project I build. Also integrated is an easy to handle workflow to make outputs as JSON, so it can be used to build responses for a REST-api as well. I will work that out in one section in the readme as well. If you want to see the module in an actual project, I have published the code of www.musical-fabrik.de in a repository. It runs completely with Twack and has an app-endpoint with ajax-output as well. I really look forward to hear, what you think of Twack?! Features Installation Usage Quickstart: Creating a component Naming conventions & component variants Component Parameters directory page parameters viewname Asset handling Services Named components Global components Ajax-Output Configuration Versioning License Changelog

Did you see the comments under 8A? # 8A. Optionally (O) set a rewrite base if rewrites are not working properly on your server. # ----------------------------------------------------------------------------------------------- # In addition, if your site directory starts with a "~" you will most likely have to use this. # https://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewritebase # Examples of RewriteBase (root and subdirectories): # RewriteBase / # RewriteBase /pw/ # RewriteBase /~user/ e.g. uncomment # RewriteBase / (remove #) and try again?

@Roope, I've noticed that the "Enable JavaScript to view protected content" notice appears for significantly longer in >= v1.2.0 than it did in v1.1.1. In the screencasts below I'm refreshing the page and I've used my browser dev tools to slow the network speed down to "Fast 3G" to make the effect more obvious. In both cases the EMO script should already be in the browser's cache. v1.1.1 v1.2.3 Is there some way to speed things up so performance is closer to the older version? A couple of other little things... 1. Could you look at appending the module version number to the JS file src as a cache-busting querystring? Without that there can be problems if you upgrade/downgrade the module and the visitor has the JS from a different version cached in their browser. 2. I wonder if the module could use a <noscript> tag in some way so that the "Enable JavaScript to view protected content" is only visible to visitors who have JS disabled. If the visitor has JS enabled but EMO has not yet decoded the email address then the notice doesn't need to be seen and this would avoid the FOUC.

This is generated on the fly when a result is rendered. Behind the scenes Renderer::renderResultDesc() and Renderer::renderResultsJson() both get field values using Renderer::getResultValue(), which in turn calls Renderer::getResultAutoDesc _auto_desc "pseudo field" (as in: not a real field) is requested. There's currently no public API for accessing this directly, but if you've got a use case that can be solved by adding one, I wouldn't be against it. Though in that case I'd like to know a bit more about the context ? Sorry! Accidentally introduced a dependency for ProcessWire 3.0.160 in the Config class. This is now fixed: latest module version (0.25.1) provides proper fallbacks for core versions prior to that.

You're right, thanks for letting me know. Links should be fixed now. I just switched to a different GitHub username and hadn't come around to updating the links yet. The docs can be found here now: daun.github.io/processwire-dashboard/

Hi there, I'm with @Neeraz - it would be great to have the possibility to also add a class to the link element (for what reason ever). Maybe @kongondo it is not a big deal for you to add that functionality to the module? That would be great ?. Have a nice Friday ?

If you do not assign a title the autogenerated ID (Inputfield) will be taken. $inputfields->attr('title', 'Weird name'); To put the Inputfields (Tabs) in the right order you could use InputfieldWrapper::insertBefore() or InputfieldWrapper::insertAfter() instead of InputfieldWrapper::add(). Unfortunately this doesn't work in case of ProcessPageEdit. To get it working you need to add another hook to ProcessPageEdit::getTabs() The following code snippet should work. Place it in your /site/ready.php wire()->addHookAfter('ProcessPageEdit::buildForm', function ($event) { $page = $event->object->getPage(); if ($page->template == "bewerbung") { $form = $event->return; $inputfields = new InputfieldWrapper(); $inputfields->attr('title', 'Weird Name'); $inputfields->attr('name+id', 'WeirdTabNameAndId'); // we need both unique ID and Name $markup = wire()->modules->get('InputfieldMarkup'); $markup->label = 'Custom Lable'; $markup->value = '<p>Just a placeholder for any custom markup</p>'; $inputfields->add($markup); $pageEditTab = $form->find('id=ProcessPageEditContent')->first(); $form->insertAfter($inputfields, $pageEditTab); // inserting in the right place is not enough to set the tab order // we need the following hook wire()->addHookAfter('ProcessPageEdit::getTabs', function ($event) { $event->return = array_merge( array_slice($event->return, 0, 1, true), array('WeirdTabNameAndId' => __('Weird Name')), // should be identical to the weird name/title above array_slice($event->return, 1, null, true) ); }); $event->return = $form; } });