elabx

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!!

Hi! Anyone got a clue on how to implement Google Recaptcha on comments forms? I don't see a way to hook into the processInput method of the CommentForm class. Maybe I'm looking at it on the wrong angle?

Could you try $page->setLanguageValue() instead?

I can at least envision a module filling up a full text search table on a page save hook! Could be pretty useful to have at hand if budget doesn't cover an ElasticSearch/Lucene/Meiliseach instance. Which is my current scenario lol

@rastographics I have also experience that the main site's search doesn't work very well either ? Maybe we should open an issue?

I have found that SQLite has full text search and it is quite fast! I built a couple million rows table and i'm very impressed!! Has anyone had any experience implementing this either in ProcessWire or in another context?

I think this would gain more visibility in the requests repository issues, I've had this issue too! I recently had a request and it got action pretty quickly. https://github.com/processwire/processwire-requests/issues

I can click the button just fine on android Chrome, but can also confirm you are not going crazy I tested in my wife's phone which is an iphone and I can replicate the behaviour! It takes too taps to click the button!

I've seen a lot of commits to support PHP 8+, so I'd say the core will most likely be stable. I'd be more worried about third party modules that might not have been updated recently, so if you are able to, I'd recommend you make a backup and test first in another install with the same environment.

If on Mac, I use ScreenFlow. I think it's a bit pricey but for me it hits the sweet spot in being easy to use and richness in features, in particular I really dig it includes a non linear editor.

Maybe a user permissions issue? It has happened to me that if the system user running the server cannot write the compiled processwire files (if compiled is turned on) it all fails. Though I do get warning in the processwire admin which you don't mention.

Hi! For some reason all my comments added through API get added in the pending state and I don't understand, has anyone had this issue?? Running this through a CLI to read a CSV. $found = $pages->findOne("name={$some_string}"); $found->of(false); $c = new Comment; $c->stars = $stars; $c->text = "$title\n$text"; $c->created = strtotime("first day of $created"); $c->set('status', 1); $c->status = 1; $found->comments->add($c); $found->save('comments'); $found->comments->each(function($item) use($found){ echo print_r($item, true); $item->set('status', 1); $item->status = 1; $found->save('comments'); }); $found->save('comments'); It would seem it has something to do to do with being created in the same request?? I am able to run this in the Tracy console and it just works ? EDIT: Just notices that the $page->comments value is empty when I run this through the CLI and the status is 1! EDIT2: I guess and empty CommentsArray is reasonable since there are not approved comments? Ended up doing: $query = wire('database')->prepare("UPDATE field_comments SET status = 1 WHERE pages_id = {$page->id}"); wire('database')->execute($query); Am I doing something wrong when creating the Comment object? That it's status doesn't get saved when saving the comments field?

damn yessss