elabx

I've used in in a couple projects and it's the "npm build thingy" (sorry i don't even know it's exact classification!) that has given me less pain points. One for a "js widget" built in Svelte (using PW as an endpoint only) and another one for a simple static website with just uikit loaded as dependency (no PW). So both very small projects, but sort of different in their purpose and both experiences were swift to get it to work! So yeah, I do like Vite haha, I feel it's quickly turning into my goto thing as far as frontend tooling goes, which used to be close to non existent. Off-topic request: It'd be rad if you could point to a repo (maybe wordpress example that could be adapted?) with a Vite setup with the regular rendering pipeline of ProcessWire, setting up the proxy for the dev server, whatever other nice thingy could be done, etc.

I don't think there's any shame in mentioning it publicly, or maybe just do it directly in the modules support's thread.

This part doesn't seem like an easy thing to refactor. How would a template file be split accorrding to template regions? It'd require some sort of cached template files created from the "template regions split" itself? Throwing this questions in the open, not specifically to Ryan. I think fragments in Blade "suffers" from the same issue in the sense that it takes the performance hit of rendering the whole template. https://github.com/laravel/framework/pull/44774 at least that's what I get from from skimming the issue.

You can take a look into the Template configuration, under Setup > Templates, and search for the template name of the page you want to configure to display an icon in the page tree. Now, in the template configuration, search for the Icon option, it might be closed down so search a bit for it, in most recent ProcessWire version it's placed in the initial tab.

Not sure if this has been mentioned?? https://github.com/uiii/processwire Not sure who the user is though to quote, but I guess this is an approach using plugins instead of post-install-cmd?? The actual composer plugin: https://github.com/uiii/pw-core

I kinda tried this and gave up lol but here's what I found: You'd probably start with the CommentFormCustom class: https://github.com/processwire/processwire/blob/master/wire/modules/Fieldtype/FieldtypeComments/CommentFormCustom.php The first comments have a little bit on how these could be used. I THINK, that something not covered is upadting the processing of the comment, so my guess is that you could implement your own "CommentFormMillipedia" for example, extending CommentForm just like CommentFormCustom, and override the processInput method, so you could process additional stuff, aside from the form fields. Although from reading the code you'd probably have to copy the whole FieldytpeComment module due to the way ComentFormCustom class is loaded. To be honest it was a bit suprised to see the comment form is not built with the Inputfields API! Maybe to allow more simplicity on the rendering?

I'd be really nice if all this was in a repository somewhere, right? But I'll take the wild (not so much) guess that this is all built through a ProcessWire website?

I also sort of have this scenario and decided to use separate Time fields to indicate start and end time of each occurrence. I just have to assume that the occurrences have the same time.

So what I did to remove the null checks was overriding the isEmptyValue() method like: public function isEmptyValue(Field $field, $value) { return true; } I am going to guess this shouldn't be just like this lol I ended up with a query like this, which also does seem faster: SELECT pages.id,pages.parent_id,pages.templates_id FROM `pages` JOIN field_event_recurring_dates AS field_event_recurring_dates ON field_event_recurring_dates.pages_id=pages.id AND (((field_event_recurring_dates.data>='2023-03-12 00:00:00' ) )) JOIN field_event_recurring_dates AS field_event_recurring_dates1 ON field_event_recurring_dates1.pages_id=pages.id AND (((field_event_recurring_dates1.data<='2023-04-11 19:52:53' ) )) WHERE (pages.templates_id=50) AND (pages.status<1024) GROUP BY pages.id -- [117.7ms] I see the selector now throws an exception when putting a blank value, I'll guess it has to do with the simplistich approach in the override laid done above. I will dig into how to properly override the isEmptyValue() for my case., getting some hints in FieldtypeTime. Thanks again for the help!

Hey crew, this is in pre-elease by the way:

If ProCache is on, you will get a static file instead of reaching PHP, so any "dynamic find()" that maybe changes over time, or is randomized, won't be really visible as you'll be seeing the version that exists in the static cache and won't change, until its built again.

I did place that code, but will work on refine it, thanks! Do you have any recommendation on to removing this? I saw it was sort of a requirement to enable pagination on fieldtypes? Is this assumption correct? Thanks a lot for your help @ryan!

Got this!! SELECT pages.id, pages.parent_id, pages.templates_id FROM `pages` JOIN field_event_recurring_dates AS field_event_recurring_dates ON field_event_recurring_dates.pages_id = pages.id AND ( ( ( field_event_recurring_dates.data >= '2023-03-09 00:00:00' ) ) ) LEFT JOIN field_event_recurring_dates AS field_event_recurring_dates__blank1 ON field_event_recurring_dates__blank1.pages_id = pages.id WHERE (pages.templates_id = 50) AND (pages.status < 1024) AND ( ( ( field_event_recurring_dates__blank1.data IS NULL OR field_event_recurring_dates__blank1.data <= '2023-04-08 10:36:35' ) ) ) GROUP BY pages.id -- [525.6ms] Would you think the id column is still hitting the performance some way?? The fieldtype's schema right now is as: $schema = parent::getDatabaseSchema($field); $schema['id'] = 'INT UNSIGNED NOT NULL AUTO_INCREMENT'; $schema['data'] = 'datetime NOT NULL'; $schema['keys']['primary'] = 'PRIMARY KEY (id)'; $schema['keys']['pages_id'] = 'UNIQUE (pages_id, sort)'; $schema['keys']['data'] = 'KEY data (data)'; Conclusion, need to wrap my head around MySQL properly, my favorite CMS has got me too spoiled haha.

It's a datetime type column and can confirm it has an index. (BTREE type shows on phpmyadmin?) I did in a bit of a trial and error (looking at the FieldtypeTable's code!) to get the field to paginate because with recurring dates things can go wild and I didn't seem to get it work without the id field, maybe I am understanding something wrong? I am going to create those missing indexes and try the get match query get back on this thread! I was actually already trying with the one from FieldtyeDatetime, so I guess I'm on the right track! Thank you so much for taking time to answer, invaluable!

Hi! I am struggling a bit with the following issue, I am working on FieldtypeRecurringDates and just realized that the query performance is very bad when querying the field through a selector, for example, on this find(); $from = date('Y-m-d H:i:s', strtotime('today')); $to = date('Y-m-d H:i:s', strtotime('+30 days')); $pages->find("event_recurring_dates>='$from', event_recurring_dates<='$to'"); I am getting the following SQL query: SELECT pages.id, pages.parent_id, pages.templates_id FROM `pages` JOIN field_event_recurring_dates AS field_event_recurring_dates ON field_event_recurring_dates.pages_id = pages.id AND ((( field_event_recurring_dates.data >= '2023-03-09 00:00:00' )) ) LEFT JOIN field_event_recurring_dates AS field_event_recurring_dates__blank1 ON field_event_recurring_dates__blank1.pages_id = pages.id WHERE ( pages.status < 1024 ) AND ((( field_event_recurring_dates__blank1.data IS NULL OR field_event_recurring_dates__blank1.data <= '2023-04-08 07:34:47' ))) GROUP BY pages.id -- [3715.9ms] As per the last comment in the last line, it runs in almost 4 seconds! In a table with liek 10k rows I think this is way too much?? I did the test of removing the LEFT JOIN, and just set a JOIN, and the performance increases dramatically, it now takes 0.0214 😮 SELECT pages.id, pages.parent_id, pages.templates_id FROM `pages` JOIN field_event_recurring_dates AS field_event_recurring_dates ON field_event_recurring_dates.pages_id = pages.id AND ((( field_event_recurring_dates.data >= '2023-03-09 00:00:00' )) ) -- Here was the LEFT JOIN JOIN field_event_recurring_dates AS field_event_recurring_dates__blank1 ON field_event_recurring_dates__blank1.pages_id = pages.id WHERE ( pages.status < 1024 ) AND ((( field_event_recurring_dates__blank1.data IS NULL OR field_event_recurring_dates__blank1.data <= '2023-04-08 07:34:47' ))) GROUP BY pages.id

I just noticed that the field doesn't really work within selectors as I expected, but working on it! 🤡 Here's the problem laid out a bit:

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')

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!

Well it's a very simple module! It just loads Alpine into the ProcessWire admin to be usable from other modules.

https://github.com/elabx/FieldtypeRecurringDates Well a few summers later, finally got like a sort of working version. For info please take a look at the repo's readme. It's still super alpha but going to deploy into a couple websites to replace Recurme so wish me luck. This module is only a Fieldtype and Inputfield, there are no "markup" modules as there used to be in Recurme. I'd appreciate any testing or any kind of comments.

Creating this thread for the AlpineJS module 🙂 https://github.com/elabx/AlpineJS

Thanks for the heads up!

Hi! Wondering if there was an example of this scenario (multiple/dynamic config inputfields) with the "new" module configuration through a separate ModuleConfig derived class?

Struggled a bit with this recently, not anymore! Thanks!!