Leaderboard

I would probably prefer to put my users under the Members page directly. That way you would still end up with your suggested page tree, but those pages would actually be the users and there would be no need to maintain a relationship between users and their pages. Have a look at this blog post for a tutorial: https://processwire.com/blog/posts/processwire-core-updates-2.5.14/#multiple-templates-or-parents-for-users

Combine the power of ProcessWire selectors and SQL Differences to previous RockFinder modules RockFinder3 comes with extensive docs ? RF3 supports chaining: $RockFinder3->find("template=foo")->addColumns(['foo']). RF3 fully supports multi-language. RF3 makes it super-easy to add custom columnTypes. RF3 makes it easier to use custom SQL statements. No bloat! The module does just do one thing: Finding data. Differences to findRaw Background: RockFinder has been there before findRaw existed findRaw makes it a little easier to query page fields, but RockFinder is more flexible in that regard RockFinder might be faster than findRaw: see here DOCS & DOWNLOAD: https://github.com/baumrock/rockfinder3 Thanks for using RockFinder3. If you find RockFinder3 helpful consider giving it a star on github or saying thank you. I'm also always happy to get feedback in the PW forum! Happy finding

ProcessWire 3.0.157 on the development branch continues the trend of core refactoring that’s been happening quite a bit in 2020. Rather than doing a rewrite every few years (like some CMS projects) we instead refactor parts as we go, constantly improving and optimizing the core. This works because the core design/architecture is right where it needs to be, even 10 years in. But there’s always still bits of legacy code, and code that can be improved. So in the context of ProcessWire, refactoring means incrementally rewriting code on the inside, without changing its behavior on the outside (other than making it faster and/or more secure). This has been happening regularly over the last 10 years, and will likewise continue happening over the next 10 years and likely beyond. This week the code behind ProcessWire’s core Database and PageFinder classes got a major refactoring. This is some of the most used code in PW, as it handles everything involved in taking a selector and converting it to a database query. But it’s always been a little bit of a pain point for me because it had to build queries in a way that I thought wasn’t ideal, in order to make it possible for lots of different modular parts (mostly Fieldtype modules) to contribute to the query and for PageFinder to put it all together. It was fast and secure, but still one of those parts that felt like a little too much duct tape to me. But considering how crucial the code is, I’ve always been reluctant to make major changes, since it all worked just fine. Spending lots of years thinking about it (on and off), a desire to work out any pain points, and having better tools available (like Phpstorm and Tracy) made it possible to finally massage out this pain point. Some work still remains to be done, but it’s mostly there and I’m feeling good about it. Stuff like this is key for the maintenance and longevity of the core, and involved a lot of time and effort, but makes very little difference to users, even if it makes a lot of difference to me in maintaining the core. It would make a boring blog post for sure—lots of work and changes, but no new toys to show for it. Nevertheless, it has that feeling of a good house cleaning, even if you can't see it from the outside. The scope of changes here means that there may actually be new bugs to work out, so to be on the safe side, consider 3.0.157 to be a little more “beta” than the dev branches usually are. Though I’m running it here on processwire.com and it’s working well. Beyond the fairly major updates to the Database classes, there are also a few new Sanitizer convenience methods that are primarily variations on existing ones, but useful ones for sure. Thanks for reading and have a great weekend!

For those not following the Rockfinder3 thread, the latest version of Tracy includes a new barEcho() / be() method that allows you to echo directly to the bar dumps panel without Tracy trying to dump it as variables / objects. You've always been able to do this directly in the Console panel with a normal echo, but now you can do the same to the bar dumps panel.

v1.0.3 adds two new features: addPath() each() Callbacks RockFinder3 supports row callbacks that are executed on each row of the result. Usage is simple: each() $RockFinder3 ->find("template=cat") ->addColumns(['title', 'weight']) ->each(function($row) { $row->myTitle = "{$row->title} ({$row->weight} kg)"; }) ->dump(); These callbacks can be a great option, but keep in mind that they can also be very resource intensive! That applies even more when you request page objects from within your callback (meaning there will be no benefit at all in using RockFinder compared to a regular $pages->find() call). addPath() A special implementation of the each() method is the addPath() method that will add a path column to your result showing the path of every page. This will not load all pages into memory though, because it uses the $pages->getPath() method internally. $RockFinder3 ->find("template=cat") ->addColumns(['title', 'weight']) ->addPath("de") ->dump(); If you need the path for linking/redirecting from your data to the pages it might be better to build a custom redirect page that works with the page id, so you don't need the overhead of getting all page paths: <a href='/your/redirect/url/?id=123'>Open Page 123</a> If you really need to access page objects you can get them via the $finder parameter of the callback: $finder->each(function($row, $finder) { $row->foo = $finder->pages->get($row->id)->foo; }

When this module is turned on, my CKEditor modals get buried under an overlay I can't obviously click through. The overlay gets set to a ridiculously high z-index. Normally the overlay sits at I think 10000 and then the modal table gets throw above that at like 10010-10060. When AOS is enabled - with no submodules activated AT ALL - there is a css override in aos.min.css and here's what it puts out in my install: .cke_dialog_background_cover { z-index: 103000 !important; } I'm not sure why that rule is in there, all that I know is that if I turn off AOS completely, it goes away. Trying to edit source code, trying to compare revisions - yeah those don't work. Am I the only one seeing this problem? It doesn't matter if the CKEditor autoload segment is turned on or not. I'm using WP 3.0.156 and AOS 2.0.20

Great idea ? I've implemented your changes on the bardump branch: https://github.com/baumrock/RockFinder3/commit/436257b8822fd89e76951db1521c8f2619ef880c Once you have your code in Tracy please tell me and I can merge to master ? The new section of the readme: Dumping data For small finders Tracy's dump() feature is enough, but if you have more complex finders or you have thousands of pages this might get really inconvenient. That's why RockFinder3 ships with a custom dump() method that works in the tracy console and turns the result of the finder into a paginated table (using tabulator.info). For all the dumping methods you can provide two parameters: The title of the dump* The settings for the rendered tabulator table *Note that if you set the title to TRUE the method will not only dump the tabulator but also the current RockFinder3 object (see the next example). dump() or d() $RockFinder3 ->find("template=cat") ->addColumns(['title', 'created']) ->dump(true); barDump() or bd() For situations where you are not working in the console but maybe in a template file or a module the barDump() method might be useful. Dumping the SQL of the finder To understand what is going on it is important to know the SQL that is executed. You can easily dump the SQL query via the dumpSQL() or barDumpSQL() methods. This even supports chaining: $RockFinder3 ->find("template=cat") ->addColumns(['title']) ->dumpSQL() ->addColumns(['owner']) ->dumpSQL() ->dump();

Process Cache Control This module provides a simple solution to clearing all your cache layers at once, and an extensible interface to perform various cache-related actions. The simple motivation behind this module was that I was tired of manually clearing caches in several places after deploying a change on a live site. The basic purpose of this module is a simple Clear all caches link in the Setup menu which clears out all caches, no matter where they hide. You can customize what exactly the module does through it's configuration menu: Expire or delete all cache entries in the database, or selectively clear caches by namespace ($cache API) Clear the the template render cache. Clear out specific folders inside your site's cache directory (/site/assets/cache) Clear the ProCache page render cache (if your site is using ProCache) Refresh version strings for static assets to bust client-side browser caches (this requires some setup, see the full documentation for details). This is the basic function of the module. However, you can also add different cache management action through the API and execute them through the module's interface. For this advanced usage, the module provides: An interface to see all available cache actions and execute them. A system log and logging output on the module page to see verify what the module is doing. A CacheControlTools class with utility functions to clear out different caches. An API to add cache actions, execute them programmatically and even modify the default action. Permission management, allowing you granular control over which user roles can execute which actions. The complete documentation can be found in the module's README. Plans for improvements If there is some interest in this, I plan to expand this to a more general cache management solution. I particular, I would like to add additional cache actions. Some ideas that came to mind: Warming up the template render cache for publicly accessible pages. Removing all active user sessions. Let me know if you have more suggestions! Links https://github.com/MoritzLost/ProcessCacheControl ProcessCacheControl in the Module directory CHANGELOG in the repository Screenshots

Developing custom fields for ProcessWire is great! And it's easier than many might think once you get the basic concepts. But it's hard to learn those concepts by reading the code and doing some trial and error... That's why I think we need a good tutorial about that topic. It took me quite long, but now I feel knowledgeable enough to write such a tutorial. I also have the idea (or the need) for some new fields that might be helpful to the community. What I don't have is time ? So I thought to share the workload and share my knowledge while the development of the module (and testing, writing docs, etc) could be done by someone else under my supervision (hope that does not sound scary ? ). What do you think? I'm happy to hear your opinions - we are in the PUB ? Have a great week and happy coding!

great - I was just preparing a report here just now. Here's a demo video: bug-aos-cke-sourceeditor.mp4

@gornycreative - https://github.com/rolandtoth/AdminOnSteroids/issues/118

Hey @bernhard - do you have support for getting fields from a page reference field? Something like: addColumns(['title', 'pagefield.title']) I feel like this should be fairly easy if the page field is a single item only. Not sure the best approach if it is set up to store references to multiple pages though. I guess this is similar to your support for the Options fieldtype where you use: "OptionsValue:sex" in the docs example. Any thoughts on whether this could be supported? I guess I could add it myself via the "columnTypes" folder, but I feel like this will be a common enough need that it should be included. Nevermind - I really should RTFM ?

@bernhard - the new barEcho() version of Tracy has been committed.

@bernhard - I've added a new "Title Prefix" option for accomplishing that. I took a quick look but don't have an easy solution at the moment without hacking the Tracy core. The core actually already has a shift+click shortcut but it's for a weird popup browser window mode which I don't support - it became too painful with some of the more complex panels I've added and I didn't see the advantage. Maybe I'll take a look again later at trying to override this, but given that we have a "maximize" panel button already, I'm not too motivated on this one.

All good now. Second installation process was successfully. Now I'm ready for testing. I want to create a directory site for local artisans. And after viewing and testing some other CMS I came to the conclusion that processwire will be the first choice and I think it's highly qualified for this case. Hope do not regret this.

Hey @adrian these new dumping upgrades will be so helpful in so many situations!! ??

@MoritzLost - huge thanks! I needed exactly such a link/module to clear all kind of cache. PW 3.0.156, PHP 7.4, OpenLiteSpeed - works like a charm. ?

There is a sort property on pages that can be set: https://processwire.com/api/ref/pages/sort/ So most likely you'll have to use the callbacks in UIkit to sort this out ?

@ryan In this version if you try to access an unpublished page that is selected in a page reference field like this: $page->page_ref_field; It returns false. In 3.0.153 it returns the (unpublished) page object. I don't know if this is expected behavior but it will break some things in my site. EDIT: Found the issue: This behaviour was changed in 3.0.155 -> https://github.com/processwire/processwire-issues/issues/1159

Thx @psy It depends on how you have used it I guess. But you can definitely run both beside each other. That's why they have separate names so that I can use them together in my projects without the need of refactoring existing code. In the long run RockFinder3 should be the only module to stay. Meaning that if you build a new project you should definitely use RF3 only and if you find anything that does not work yet with RF3 just give me a ping and I'll implement it. Most of that should be easy and maybe just copy&pasting methods from RF2 to RF3 and doing some refactoring. So I guess the answer is: It is a completely different module ?

Hi Horst, I already using ProCache with nginx, but only for static pages like blog posts and articles. I think PW altar database even if you are not log in. For example if page is not found. The site is sport related with live stats. Initial data is loaded when the page is loaded. Then all changes on events are served via websocket in real time. Thank you for your answer! I'm going to reorganize the site before it is too late.

Hi @bernhard love your work. Is RF2 upgradeable to RF3 or is RF3 a completely different module?

No worries! We can help you with the 'internal server error' bit if you could tells us or show us the script that was used to generate the footer menu. It is most likely being called from one of your /site/templates/something.php

Thank you very much for your help - and suggestions. As it's not a big site I'm more or less starting from scratch using parts of the old 'site' folder at a time so that it is easy [!] to roll back changes. I'm also using it as a brain activity - I've been meaning to learn about php & cms for a few years now, ever since people stopped wanting me to develop html sites! So once again, thank you - and I'll probably be back!! Latest: http://vivesport.co.uk/

Hey @bernhard - attached is a new version that loads Tabulator if someone wants to make a dump() call directly to the page within their template file. Basically it just duplicates the JSloader functionality within this module. I was also thinking about maybe making a barDump() version that would emulate bd() but with Tabulator output, but didn't get there yet. I decided to take a look at adding a barDump() option. To test you'll need the new Rockfinder and TD.php files attached. Now you can call the new barDump() method from anywhere (including template files, and the Console panel) and Tracy Dumps panel will receive the tabulated output, or the dumped object if you pass "true" for the title. Please test thoroughly and feel free to tweak behavior as needed. I should note that I changed the return for the dump method from $this to $out. I guess this will break chaining if someone wants to add another method after this. Maybe there is a better way to do this but was in a hurry. RockFinder3.module.php TD.php

Hi @szabesz, Good idea... I deleted the 1st version of the script and put the second one in a spoiler. I couldn't figure out how to delete an empty spoiler or code block. Do you know how? Edit: I figured it out: just go below the empty box and hit the backspace key until it's gone. ? Thanks again, Peter

It's fun and wildly different to what I'm used to. It's tight integration with VS Code makes learning much easier. Definitely worth a look

To give another perspective on this topic... This is something that is much easier fixed by changing host than changing the website itself. A statement like that is a clear message that it's time to find a different host. I think it's outrageous for a host to change the PHP version on a live site without warning and then tell their customers that it's their problem to solve. If a host did that to me I would drop them just on principle. Almost all shared cPanel hosting lets you pick the PHP version. So my suggestion would be to open a new account at a shared cPanel host of your choosing. This kind of hosting is as cheap as chips. Hopefully you made a backup of the site files and database before you started changing things. Set the PHP version to 5.4, create/import the database and upload the files and chances are everything will work as it did before. The host might even do the migration for you as a sweetener for new customers. You can use a subdomain (test.vivesport.co.uk) for testing the new hosting and later change the primary domain if everything is working.

Cool men ? Thanks in advance guys!

I really don't care a lot about those things (neither the plus icon nore the favicon), but couldn't you also set the page title to something like: #DEV# xxx on the dev site and leave the favicon untouched? ?

Thx for the interest everybody! I'm in contact with @elabx and @Sephiroth and we will try to build something useful and document the process so that everybody can learn from it. Similar to what ryan planned with the events fieldtype, but step by step, so it's easier to follow ?

I've seen a couple of questions regarding namespaces and autoloading floating around the forum recently, so I decided to write a little tutorial. In general, I often see people getting confused when they try to wrap their head around namespaces, autoloading, Composer and the mapping of namespaces to directory structures all at once. In fact, those are very much independent, distinct concepts, and it is much easier to explain and understand them separately. So this guide is structured as follows: How namespaces work in PHP. How autoloading works in PHP. Conventions for mapping namespaces to directory structures: PSR-4. How autoloading works in Composer and ProcessWire's class loader. How to use the class loader in a ProcessWire module. Feel free to skip the sections you're already familiar with. Namespaces in PHP The purpose of namespaces in PHP is to avoid naming conflicts between classes, functions and constants, especially when you're using external libraries and frameworks. Nothing more. It's important to understand that this has nothing at all to do with autoloading, directory structures or file names. You can put namespaced stuff everywhere you want. You can even have multiple namespaces inside a single file (don't try this at home). Namespaces only exist to be able to use a generic name – for example, ProcessWire's Config class – multiple times in different contexts without getting a naming conflict. Without namespaces, I couldn't use any library that includes a Config class of it's own, because that name is already taken. With namespaces, you can have a distinction between the classes ProcessWire\Config and MoritzLost\Config. You can also use sub-namespaces to further segregate your code into logical groups. For example, I can have two classes MoritzLost\Frontend\Config and MoritzLost\Backend\Config– a class name only needs to be unique within it's namespace. You can declare the namespace for a PHP file using the namespace statement at the top: // file-one.php <?php namespace ProcessWire; // file-two.php <?php namespace MoritzLost\Frontend; This way, all classes, methods and constants defined inside this file are placed in that namespace. All ProcessWire classes live in the ProcessWire namespace. Now to use one of those classes – for example, to instantiate it – you have a couple of options. You can either use it's fully qualified class name or import it into the current namespace. Also, if you are inside a namespaced file, any reference to a class is relative to that namespace. Unless it starts with a backward slash, in this case it's relative to the global namespace. So all of those examples are equivalent: // example-one.php <?php namespace ProcessWire; $page = new Page(); // example-two.php <?php use ProcessWire\Page; $page = new Page(); // example-three.php <?php $page = new ProcessWire\Page(); // example-four.php <?php namespace MoritzLost\Somewhere\Over\The\Rainbow; $page = new \ProcessWire\Page(); The use statement in the second example can be read like this: “Inside this file, all references to Page refer to the class \ProcessWire\Page” How autoloading works Every PHP program starts with one entry file – for ProcessWire, that's usually it's index.php. But you don't want to keep all your code in one file, that would get out of hand quickly. Once you start to split your code into several individual files however, you have to take care of manually including them with require or include calls. That becomes very tedious as well. The purpose of autoloading is to be able to add new code in new files without having to import them manually. This, again, has nothing to do with namespaces, not even something with file locations. Autoloading is a pretty simple concept: If you try to use a class that hasn't been loaded yet, PHP calls upon it's registered autoloaders as a last-ditch attempt to load them before throwing an exception. Let's look at a simple example: // classes.php <?php class A { /** class stuff */ } class B { /** class stuff */ } // index.php <?php spl_autoload_register(function ($class) { include_once 'classes.php'; }); new A(); new B(); This is a complete and functional autoloader. If you don't believe me, go ahead and save those two files (classes.php and index.php) and run the index.php with php -f index.php. Then comment out the include_once call and run it again, then you'll get an error that class A was not found. Now here's what happens when index.php is executed (with the autoloader active): Our anonymous function is added to the autoload queue through spl_autoload_register. PHP tries to instantiate class A, but can't because it's not loaded yet. If there was no autoloader registered, the program would die with a fatal error at this point. But since there is an autoloader ... The autoloader is called. Our autoloader includes classes.php with the class definition. That was a close one! Since the class has been loaded, execution goes back to the index.php which can now proceed to instantiate A and B. If the class was still not loaded at this point, PHP would go back to the original plan and die. One thing to note is that the autoloader will only be called once in this example. That's because both A and B are in the same file and that file is included during the first call to the autoloader. Autoloading works on files, not on classes! The important takeaway is that PHP doesn't know if the autoloader knows where to find the class it asks for or, if there are multiple autoloader, which one can load it. PHP just calls each registered autoloader in turn and checks if the class has been loaded after each one. If the class still isn't loaded after the last autoloader is done, it's error time. What the autoloader actually does is pretty much wild wild west as well. It takes the name of the class PHP is trying to load as an argument, but it doesn't have to do anything with it. Our autoloader ignores it entirely. Instead, it just includes classes.php and says to itself “My job here is done”. If class A was in another file, it wouldn't have worked. This process has two main advantages: Since autoloaders are only called on-demand to load classes just in time, we only include the files we actually need. If in the example above class A and B are not used in some scenarios, the classes.php will not be included, which will result in better performance for larger projects (though this isn't as cut and dry, since autoloading has it's own overhead, so if you load most classes anyway during a single request, it will actually be less efficient). If the autoloader is smart enough to somehow map class names to the files they're located in, we can just let the autoloader handle including the classes we need, without having to worry about jamming include statements everywhere. That brings us to ... PSR-4, namespaces and directory structures As you see, namespaces and autoloading are both pretty limited concepts. And they aren't inherently linked to each other. You can namespace your classes without ever adding an autoloader, and you can autoload classes that are all in the same namespace. But they become useful when you put them together. At the core of all that autoloading talk is a simple idea: By putting classes in files named after their class names, and putting those files in directory hierarchies based on the namespace hierarchy, the autoloader can efficiently find and load those files based on the namespace. All it needs is a list of root namespaces with their corresponding directories. The exact way class names and namespaces are mapped to directory structures and file names is purely conventional. The accepted convention for this is PSR-4. This is a super simple standard which basically just sums up the ideas above: A base namespace is mapped to a specific directory in the file system. When the autoloader is asked to load a class in that namespace (or a sub-namespace of it), it starts looking in that folder. This "base" namespace may include multiple parts – for example, I could use MoritzLost\MyAwesomeLibrary as a base and map that to my source directory. PSR-4 calls this a "namespace prefix". Each sub-namespace corresponds to a sub-directory. So by looking at the namespace, you can follow subdirectories to the location where you expect to find the class file. Finally, the class name is mapped directly to the file name. So MyCoolClass needs to be put inside MyCoolClass.php. This all sounds simple and straightforward - and it absolutely is! It's only once you mash everything together, mix up language features, accepted conventions and proprietary implementations like Composer on top that it becomes hard to grasp in one go. Composer and ProcessWire's class loader Now all that's left is to talk about how Composer and ProcessWire provide autoloading. Composer, of course, is primarily a tool for dependency management. But because most libraries use namespaces and most developers want to have the libraries they're using autoloaded, those topics become a prerequisite to understanding what Composer does in this regard. Composer can use different autoloading mechanisms; for example, you can just give it a static list of files to include for every request, or use the older PSR-0 standard. But most modern libraries use PSR-4 to autoload classes. So all Composer needs to function is a mapping of namespace prefixes to directories. Each library maintains this mapping for it's PSR-4-structured classes through the autoload information in their composer.json. You can do this for your own site to: Just include the autoload information as shown in the documentation and point it to the directory of your class files. Composer collects all that information and uses it to generate a custom file at vendor/autoload.php — that's the one you need to include somewhere whenever you set up Composer in one of your projects. Bells and whistles aside, this file just registers an autoloader function that will use all the information collected from your own and your included libraries' composer.json to locate and include class files on demand. You can read more about how to optimize Composer's autoloader for production usage here. If you want to read up on how to set up Composer for your own sites, read my ProcessWire + Composer integration guide instead. And finally, what does ProcessWire do to handle all this? Turns out, ProcessWire has it's own autoloader implementation that is more or less PSR-4 compliant. You can access it as an API variable ($classLoader or wire('classLoader'), depending on context). Instead of using a static configuration file like Composer, the namespace -> directory mapping is added during the runtime by calling $classLoader->addNamespace. As you would expect, this function accepts a namespace and a directory path. You can use this to register your own custom namespaces. Alternatively, if you have site-specific classes within the ProcessWire namespace, you can just add their location to the class loader using the same method: $classLoader->addNamespace('ProcessWire', '/path/to/your/classes/'). Utilizing custom namespaces and autoloading in ProcessWire modules Now as a final remark, I wanted to give an example of how to use custom namespaces and the class loader in your own modules. I'll use my TrelloWire module as an example: Decide what namespace you're going to use. The main module file should live in the ProcessWire namespace, but if you have other classes in your module, they can and should use a custom namespace to avoid collisions with other modules. TrelloWire uses ProcessWire\TrelloWire, but you can also use something outside the ProcessWire namespace. You need to make sure to add the namespace to the class loader as early as possible. If either you or a user of your module tries to instantiate one of your custom classes before that, it will fail. Good places to start are the constructor of your main module file, or their init or ready methods. Here's a complete example. The module uses only one custom namespaced class: ProcessWire\TrelloWire\TrelloWireApi, located in the src/ directory of the module. But with this setup, I can add more classes whenever I need without having to modify anything else. /** * The constructor registers the TrelloWire namespace used by this module. */ public function __construct() { $namespace = 'ProcessWire\\TrelloWire'; $classLoader = $this->wire('classLoader'); if (!$classLoader->hasNamespace($namespace)) { $srcPath = $this->wire('config')->paths->get($this) . 'src/'; $classLoader->addNamespace($namespace, $srcPath); } } Source Thanks for making it through to the very end! I gotta learn to keep those things short. Anyway, I hope this clears up some questions about namespaces and autoloading. Let me know if I got something wrong, and feel free to add your own tips and tricks!

@bernhard I am up for it if you can share the knowledge, I can write an article around it as a tutorial since I tend to write tutorials. Ironically this was part of a series I am creating for Processwire, just video editing skills delaying but writing this as a tutorial shouldn't be a problem. Just let me know what you need me to do, I will create time for this. Take care

☝️ I'd love to help while learning! In my personal experience Fieldtype/Inputfield development is like one of the few things of the modular approach of ProcessWire that isn't completely clear to me, so I think a tutorial would be super useful for a lot of people. I'd like to stop abusing RuntimeMarkup some day haha (which is and awesome module of course!)

yes, sorry for being very vague about the reply. I solved this issue as below mentioned method

It's not documented but you can use two curly braces to achieve de-emphasised text:

Really great idea @Robin S ! You can make it even less work by using d($td_host) in the Console panel:

Hi all, Just wanted to share a tip that can be useful if you want to debug a core file before Tracy has been loaded. Suppose you were debugging ProcessWire::getHttpHost() and for some reason wanted to dump the $host variable just before it is returned. If you add the line... bd($host, 'host'); ...then you'll get a fatal error when the code runs because Tracy has not yet been loaded and so the bd() function is undefined. When debugging core files you'll find a number of places like this where the Tracy dump functions are not available. A workaround for this is to set the variable that you want to dump as a custom property on the Wire object. You want to be careful not to use a property name that clashes with any existing Wire properties or API variables - adding a prefix like "td_" is a safe bet. $this->wire()->set('td_host', $host); Now in /site/ready.php you can dump the variable that you stored on the Wire object: bd($wire->td_host, 'host'); ...or shorter (thanks @adrian)... bd($td_host, 'host');

I created this module a while ago and never got around to publicising it, but it has been outed in the latest PW Weekly so here goes the support thread... Unique Image Variations Ensures that all ImageSizer options and focus settings affect image variation filenames. Background When using methods that produce image variations such as Pageimage::size(), ProcessWire includes some of the ImageSizer settings (height, width, cropping location, etc) in the variation filename. This is useful so that if you change these settings in your size() call a new variation is generated and you see this variation on the front-end. However, ProcessWire does not include several of the other ImageSizer settings in the variation filename: upscaling cropping, when set to false or a blank string interlace sharpening quality hidpi quality focus (whether any saved focus area for an image should affect cropping) focus data (the top/left/zoom data for the focus area) This means that if you change any of these settings, either in $config->imageSizerOptions or in an $options array passed to a method like size(), and you already have variations at the requested size/crop, then ProcessWire will not create new variations and will continue to serve the old variations. In other words you won't see the effect of your changed ImageSizer options on the front-end until you delete the old variations. Features The Unique Image Variations module ensures that any changes to ImageSizer options and any changes to the focus area made in Page Edit are reflected in the variation filename, so new variations will always be generated and displayed on the front-end. Installation Install the Unique Image Variations module. In the module config, set the ImageSizer options that you want to include in image variation filenames. Warnings Installing the module (and keeping one or more of the options selected in the module config) will cause all existing image variations to be regenerated the next time they are requested. If you have an existing website with a large number of images you may not want the performance impact of that. The module is perhaps best suited to new sites where image variations have not yet been generated. Similarly, if you change the module config settings on an existing site then all image variations will be regenerated the next time they are requested. If you think you might want to change an ImageSizer option in the future (I'm thinking here primarily of options such as interlace that are typically set in $config->imageSizerOptions) and would not want that change to cause existing image variations to be regenerated then best to not include that option in the module config after you first install the module. https://github.com/Toutouwai/UniqueImageVariations https://modules.processwire.com/modules/unique-image-variations/

Ok, I got some updates on this module. I wanted to implement support of multiple forms on one page because I need to add a newsletter subscription form on one page using my module and right now this is not possible. Unfortunately this task is not trivial and I hope to get some help by you guys ? maybe @tpr @Robin S or @gebeer have already done something similar? Please see the explanation of the issue in the Nette Forum: https://forum.nette.org/en/30969-multiple-forms-on-one-page-standalone-version Edit: seems to be solved - got a reply instantly in the nett forum ? BTW: I decided to remove the branding from the module ?

2018 update: You can also use strtotime in selectors since a while (don't know in wich PW version, but it works in versions > 3. So you could do: $pages->find('template=invoice,created>"first day of this month",created<"last day of this month"'))