Leaderboard

@gebeer We're running the module on a couple of sites on PHP 8.0 and 8.1 with no issues. If you do find any issues running on PHP 8+, open an issue on GitHub or let me know here and I will fix it as soon as possible!

The main ideas behind this update are Migrating the frontend to a "reactive js framework" which I think simplified the frontend code A LOT. So the UI is powered by Alpine.js. Migrating the database schema to use Date column to store event occurrences as data, not as text within one row. Not sure if warn people that this could get out of control easily in the sense that you could store whatever thousands of pages the computer can handle lol. The data can now be queried by the date column and it uses the regular date selectors we are used to, you can also paginate the results of each occurrence definition and it will paginate them form the dabase, making it more efficient in general than how it was built previously. So you can to something like: $page->recurring_dates_field('start=20, limit=100')

Hi @kongondo, thank you for your feedback. Since you still ask for wishes for the new version, here are two more. 😃 Just like the focus point, it would be very helpful to save the image description differently per page base. Example: I want to use a image several times in an article, but I want a different caption in each article. And the biggest wish I have to pass on: Folder, folder, folder. My clients love thinking in folders. It doesn't even have to be a real folder for PW, but just a "fake page tree". The main thing is to have the feeling of having something organised. In this context, a configuration would of course be necessary, where you can, for example, specify where the image is automatically categorised when uploading. An example of how it is solved, for example, in the WP-media Library as an extra plugin. Article: https://devowl.io/2020/create-folders-in-wordpress-media-library/

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 🙂

I have more and more customers complaining that they can't upload webp images. I understand that webp is not the ideal master image format, but neither is jpeg. The webp browser support is also so good now that it would not be necessary to generate jpeg/png versions from webp.

Thank you Moritz!

Have you tried "alojamiento_combo.category.name=$segmento1"? If that doesn't work, then, as far as I understand the docs, you'll probably need to convert the name in your URL segment to a full path (e.g. "/categorias/domo/" or wherever in your structure the category is located). The docs say: You could of course retrieve the category in a separate query and use the return in your selector. $categoria = $pages->get("template=categoria, name=$segmento1"); $filter = $pages->find("template=alojamiento, alojamiento_combo.categoria=$categoria, sort=random, limit=20");

@MoritzLost is your module ready for PHP 8?

Hi @bernhard - I think the easiest way might be to set: Debugger::$editorMapping which I think you should be able to change in config.php Here is where the path is built: https://github.com/adrianbj/TracyDebugger/blob/f2fbcd88fcecad45b2ce7b428cfe80c1527c1122/TracyDebugger.module.php#L1004-L1048 but I think in your case you will want to get the current value of Debugger::$editorMapping and do a str_replace on the path set in the module setting to adjust for each user as needed. You could probably even just put a placehholder like "localpath" in the module settings and replace that with the correct path per user. Let me know if that works out for you.

Same experience with our clients. They are coming from TYPO3 and are used to organize media in folders. Trying to explain that the MM approach is much more flexible. But they'd still love to have their folders back. Technically this would mean that there is some kind of default categorisation apart from media type. I think using tags would be the best and most flexible method.

This is done as a regular Fieldtype under a `data` column, it basically looks like a Datetime field db table, and there is a secondary table that saves the field settings in terms of UI state. I might need to still to a bit of cleanup in this because I was going to include an "exclude" boolean column, to skip specific dates in an occurrence rule, but I am thinking of changing that approach. I set a hard limit through either count limit, or a date. This is basically a limitation of the php-rrule library itself, as you WILL end with an infinite loop if either COUNT or UNTIL parts of the rule are not set. So if I remember correctly now, the module should even throw an error if you try to save something without one or the other value. I want to implement a "Never" option, but the only way I can think of it is to depend on a hidden hard limit, and a async task that "recalculates the rule" in the database. In the previous module it didn't recalculate, it just assumed you'd never reach the 50k iteration of the occurrence lol, I'm surprised it has actually worked pretty well until now.

To be honest this wasn't a very conscious decision it just felt kinda odd to define it within the Fieldtype module? I also though of it to be able to combine with other Date module fields through a hook in the finder, I'll set an example as soon as I can too, since this definitely needs documentation. Yes I will upload a GIF as soon as I can! I'm not sure there is a lot to say?? In general I feel it's overall regular Fieldtype/Inputfield development. Which took me some time to grasp lol. (Thanks @MarkE for your fieldtype breakdown!). Also de UI is built with Alpine.js. And the heavy lifting (calculating the occurrences) is done by php-rrule. Ok after writing this I'm thinking it might be worth to explain myself a bit more haha. Thanks mate!

Your list is exactly what I wish for as well, I have nothing to add. I gave it a thumbs-up. Ryan's time to work on ProcessWire is limited and being the only one to stear the boat, naturally, he needs to prioritize. I think the most important issue with implementing and maintaining migrations is that it is a HUGE effort, and Ryan would need to add support for his Pro modules as well. Again, he only has 24 hours a day. I cannot even imagine who would have the time to rewrite the admin theme from scratch. However, if Ryan ever wants to move it forward to the next level, he needs to move his mindset to the reactive era, probably HTMX + Alpine.js. If we drop support for the others, people would surely use AdminThemeUikit :P

I'm in! Maintaining AOS would be just too much work for even the most experienced, I think, so no wonder @tpr is no longer interested in it, especially that he no longer uses ProcessWire. Also, AOS mostly supports the Default or Reno admin themes which we should deprecate, IMHO.

Hi.

It doesn't work on frontend, it requires the Fieldtype. http://modules.processwire.com/modules/fieldtype-map-marker/ read comments. Edit: Maybe it still works. https://processwire.com/talk/topic/10110-cant-get-inputfieldmapmarker-working-on-frontend/