Leaderboard

@wbmnfktr I checked our list and don't see your email is on it. So next I checked the list activity log and see that we got 3 bounces from your email about 2 years ago. After 3 bounces it removes you from the list, as Mailgun doesn't like it if we keep sending to an address that bounces. I think it can be solved just by re-subscribing. Please let me know if you find it doesn't. Thanks.

Yes! Seriously, someone pls email @ryan about this. If no one else will do it, I'll do it. My new favorite ProcessWire infographic:

TL;DR Just copy this folder to your module and get fully automated releases, tags, changelog and with one additional line of code (see note below!!) also fully automated version numbers for your PW modules! Background/long story: @dotnetic asked me some time ago to use conventional commits for my modules. It was totally new to me, here is the link: https://www.conventionalcommits.org/en/v1.0.0/ I've since adopted that workflow to most of my modules, as it is really just copy and pasting the .workflow folder (and you can simply copy that folder from RockFrontend: https://github.com/baumrock/RockFrontend/tree/main/.github/workflows) This workflow is great, because It will create new releases automatically for you: https://github.com/baumrock/RockMigrations/releases It will create new tags automatically for you: https://github.com/baumrock/RockMigrations/tags (This is something that I always forgot and someone was asking for it long time ago, because tags are important if someone uses composer to manage their modules, as far as I understood. Now I can't forget them any more ? ) It will create a changelog for you automatically: https://github.com/baumrock/RockMigrations/blob/main/CHANGELOG.md And last but not least: It will create version numbers automatically for you. One thing that has always been annoying though is that you have to make sure that the version number that is automatically created matches the version number that you set in your modules .module.php or .info.php file. I have always tended to have everything in my .module.php file, but I just recently noticed that this can lead to problems if you are using PHP8 syntax in your module and the website still runs on PHP version <8 --> You end up getting a fatal error whenever the module is loaded, which totally breaks ProcessWires module backend. The solution is easy though: Just split your module config into two files - the .module.php with all the module's logic and the .info.php file with only the array that defines the module's info array. Thx for that reminder @BitPoet! Here is the HelloWorld's info.php file with some helpful comments: https://github.com/ryancramerdesign/Helloworld/blob/master/Helloworld.info.php I did that today for RockMigrations and I realised that you can even fully automate the version numbering of your module, because the conventional commit workflow creates a package.json file that holds the version number in a json string: https://github.com/baumrock/RockMigrations/blob/main/package.json All you have to do is to grab that json string and write that version into your module's info.php file: https://github.com/baumrock/RockMigrations/blob/92a33ba4e7146a69fb1f52d5b67270b66d9f1e54/RockMigrations.info.php#L5-L9 Afraid of a performance penalty? You don't have to. The module's info is cached by PW and only updated on modules::refresh! Maybe other module authors like @adrian or @Robin S or @kongondo or @teppo or @netcarver or @Macrura or @flydev want to adopt that workflow as well. Thx for reading and have a great weekend ?

This week the focus was on core updates and we have a quality mixture of minor issue fixes, pull request additions, and other improvements in ProcessWire on the dev branch. My favorite addition was from a PR by @matjazp that makes improvements to ProcessWire's pagination module, MarkupPagerNav. See more updates and PRs in the dev branch commit log as well. There's still more to add before we bump the version to 3.0.214, so stay tuned for that next week. By the way, if you've recently launched any new sites in ProcessWire, please add them to our sites directory. I think most of us are already subscribed to the ProcessWire Weekly email, but just in case you aren't, you can subscribe here. The email content is from weekly.pw written by @teppo and is great to read, highly recommended! Thanks and have a great weekend!

Hi! I am trying to build a new version (open source) of the recurring dates module released a few years ago. And I've found myself with a couple doubts. I am building it as a single value Fieldtype module where I want to save the rrule string (to render the UI) but I want to save the actual occurrences of the rule in a second table, so I can use mysql to query the actual dates. Does this make sense? Is there another field around that uses a secondary table to save data? If this is sensible, where should I do it?? sleepValue()? savePageField()? @adrian I think I saw you suffering with the bugs a lot around the support thread haha, so any input on how you would approach the development/refactors of this would be appreciated. Right now on the "big picture" I want to use Alpine.js to redo de Inputfield and looking for advice here on how to do the actual Fieldtype. Also it's the plan to completely rely on rlavin/php-rrule . And this module will only involve the fieldtype/inputfield not the whole rendering modules that came along the original one.

Hey Adrian I get this error on the latest version. Thx in advance ? ErrorException: Undefined variable $toMethodName in /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/panels/DebugModePanel.php:216Stack trace:#0 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/panels/DebugModePanel.php(216): Tracy\Bar->Tracy\{closure}(2, 'Undefined varia...', '/var/www/html/s...', 216)#1 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.9.x/src/Tracy/Bar/Bar.php(145): DebugModePanel->getPanel()#2 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.9.x/src/Tracy/Bar/Bar.php(117): Tracy\Bar->renderPanels('')#3 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.9.x/src/Tracy/Bar/Bar.php(91): Tracy\Bar->renderPartial('main')#4 /var/www/html/site/modules/TracyDebugger/tracy-2.9.x/src/Tracy/Debugger/DevelopmentStrategy.php(139): Tracy\Bar->render(Object(Tracy\DeferredContent))#5 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.9.x/src/Tracy/Debugger/Debugger.php(321): Tracy\DevelopmentStrategy->renderBar()#6 [internal function]: Tracy\Debugger::shutdownHandler()#7 {main}

Thanks @bernhard - not sure why I haven't seen that issue before - it's been a bug for a long time. Should be fixed in the latest version.

Nothing really. You just make sure PhpStorm is listening then run “ddev debug”.

A really great write-up! Should find its way into the Showcase...!

OMG solved! ? When I was digging into wire/core/WireHTTP I think the file got corrupted, maybe during an upload to my dev server (yes, still staging) Replaced it with a new copy and site is working again @netcarver truly appreciate your help and patience.

I hope we all together can keep this project stay alive, and make it a super-awesome-meta-collection-of-goodness for ProcessWire. There are so many awesome solutions and answers to common questions and challenges for whatever task buried deep into the forums. From basic questions to full-blown Pro module solutions. Maybe we all should be more sensitive to answers and solutions we get and at least should think about submitting those answers to the repository. In my opinion this repo/project should have the goal to be the starting point for all ProcessWire Newcomers. From easy tutorials to advanced setups. BUT... that's just my thought for the moment. To make this whole project NOT my personal project, I will add more and more people from our community as maintainers/owners to this whole repo and will think about a solution to find a way to finance the domain without me. But those are future tasks. Just wanted to let you know. It's not about me, but the thought behind all this!

Thank you, @gebeer for the awesome feedback. I love that idea! I wish we could create some sort of snippet collection (right now) from all of these recipes in some kind or another. While it would be quite easy for me to export each recipe to another format of almost any kind, almost each and every recipe has to follow some or all rules of formatting. Right now... the formatting is super basic but we can work on it and even could create snippets for only those recipes that support the wanted formatting. I could export those snippets, each and every time into another repository, when a recipe get's flagged as "isSnippet=true". If we can find a workable solution and formatting for real snippets... I'm here to support it! But first we should define a default/standard format for recipes and go from there. I wish we could go through all of the recipes to make them some kind of uniform, working with ProcessWire 2+, and mark those which only work with ProcessWire 3, or whatever version of ProcessWire, just to find a solid foundation. From there we could work out a snippet format and necessary fields, export them and even publish them to whereever we want. Something I forgot... there are snippets, ready.php snippets, common hook snippets... and probably more... so we have to classify snippets and recipes right from the start in some kind. But sure... that's possible. This will be fun! I really love this idea.

@wbmnfktr Thank you so much for breathing life back into this project. Website already looks awesome. I have an idea/suggestion: it would be great if all the code snippets could easily be integrated and used in our IDE. With the current way of how they are stored on GH I wouldn't how this could be achieved. There is a vscode extension that lets you use gists as code snippets. So if the actual code snippets were organized in gists it would be possible to use those from within the IDE. Maybe there is an automated way of storing all snippets as gists from within your build process?

@Matzn Are you wanting a parent/child class relationship, or are parent and child modules separate modules where you want the child module to pull a value from the parent module? If you just want to pull a configuration value from "ParentModule" to use somewhere in "ChildModule" (or anywhere else) then you don't need to have a parent/child relationship between the modules and can instead just pull the value you need: $api_user = $modules->getConfig('ParentModule', 'api_user'); On the other hand, if you really do want a parent/child relationship between the module classes, and they will be two separate installed modules, then it is possible. Many Inputfield and Fieldtype modules use this approach. For instance, InputfieldCKEditor extends InputfieldTextarea, and InputfieldTextarea extends InputfieldText. The reason is that they all have similar configuration needs, as they are all inputs for text. InputfieldCKEditor builds upon the configuration of InputfieldTextarea and InputfieldTextarea builds upon the configuration of InputfieldText. When it's possible that someone might attempt to install the ChildModule without having first installed the ParentModule then it's recommended to keep your module-info in a separate php (or json) file like ModuleName.info.php, at least for the modules that require another (i.e. ChildModule requires ParentModule). This ensures that if ChildModule is on the file system, but ParentModule isn't, PW can identify the requirements for the ChildModule without having to load its class file. (If it loaded its class file, then it would result in an error since ChildModule extends ParentModule, and ParentModule isn't present, so that's why we want to avoid that). Let's say we've got this ParentModule: // ParentModule.module.php class ParentModule extends WireData implements Module, ConfigurableModule { public function __construct() { $this->set('api_user', ''); // establish default value parent::__construct(); } public function getModuleConfigInputfields(InputfieldWrapper $inputfields) { $f = $this->wire()->modules->get('InputfieldText'); $f->attr('name', 'api_user'); $f->label = 'API User'; $f->required = true; $f->val($this->get('api_user')); $inputfields->add($f); } } And it also has this ParentModule.info.php file to define module info. Since ParentModule doesn't extend another module, it could also be in a static getModuleInfo() method if you preferred it, but we'll stick to the file for this example: // ParentModule.info.php <?php namespace ProcessWire; $info = array( 'title' => 'Parent module', 'version' => 1, 'summary' => 'Parent module description', ); Here's a child module that extends ParentModule and also adds an "api_key" to the configuration: // ChildModule.module.php class ChildModule extends ParentModule implements Module, ConfigurableModule { public function __construct() { $this->set('api_key', ''); // default value parent::__construct(); } public function getModuleConfigInputfields(InputfieldWrapper $inputfields) { parent::getModuleConfigInputfields($inputfields); $f = $this->wire()->modules->get('InputfieldText'); $f->attr('name', 'api_key'); $f->label = 'API Key'; $f->required = true; $f->val($this->get('api_key')); $inputfields->add($f); } public function test() { $this->message("API user is $this->api_user and key is $this->api_key"); } } …and the ChildModule's info file is below. Note the "requires" that says it requires ParentModule: // ChildModule.info.php <?php namespace ProcessWire; $info = array( 'title' => 'Child module', 'version' => 1, 'summary' => 'Child module description', 'requires' => 'ParentModule', ); Zeka's example above is also a good one, but just adding my example as another variation.

Hi Guys, I think I finally solved this Or at least, I solved it for my case. The problem I had with this was that I used a form which submitted the page to a "www." variant of the page while all other standard pages where rendered without the "www.". By changing this in the config.php file I was able to keep all session variables and cookies (which previously also got dropped) $config->httpHosts = array( 'processwire.com', // our primary hostname 'www.processwire.com', // alternate hostname 'dev.processwire.com', // staging server 'localhost:8888' // MAMP local dev server ); I changed the one first to a www. variant, and the second one to a non-www. variant. in /site/config.php I hope this helps someone in the future! Bram

I'm not exactly sure what you're thinking "combine" means here, but this field does exactly what the description says; it grabs data from other fields, mashes it all together into one big blob of (JSON) content -- and that's just about it. One very simple (yet sometimes very practical) use case is if you've got, say, 15 different text fields and you need to find pages that contain value "john doe" in any of those. Instead of doing this: $john_does = $pages->find('field1|field2|field3|field4|field5|...|field15%="john doe"'); .. you can create a cache field, select all of those fields to be cached in it, and then do this: $john_does = $pages->find('my_cache_field%="john doe"'); Not only does this look clean, in certain situations it can wildly improve query performance.