teppo

Sounds just about right to me, yes. At least for my use cases that would be a big leap forward; it would put me/us to control of when and where scheduled tasks run 🙂 I do like the database approach of WP cron because it gives me clear view of the landscape, so to speak, but honestly that may not be necessary at all. And perhaps something very similar can already be achieved.

Hey @ryan! In my case the main benefit of wp-cron is that the system keeps track of registered/queued jobs and lets me disable the request based execution and run them via real cron. This is a common practice, and I would even go as far as say that the request-based way of running queued tasks is mostly intended for shared hosting etc. where real cron may not be available. For this purpose wp-cron keeps track of scheduled jobs in the database, and has a config setting for disabling the "lazy" (request based) execution: define('DISABLE_WP_CRON', true) Once you've done this, you can set up a cron job, systemd task, or something similar that runs queued jobs, typically on a short interval (e.g. once a minute), so that you have almost-exact executions: * * * * * wp cron event run --due-now Basically wp-cron is a standard, system-wide way to register jobs to a queue, and keep track of which jobs have been registered and when, how often they should run, and when the next run time is. Those with no access to real cron (or some reason not to use it) can keep using the lazy approach, while those that don't want the jobs tied to web requests can set up a single cron job instead of e.g. many task-specific jobs. (And this also makes it a bit easier to e.g. set up a separate worker machine that just runs cron jobs.) I have a feeling that you may have looked at their default way to run jobs; you are right that at the surface level that looks very similar to LazyCron. But in my opinion this is actually the least important part of wp-cron 🙂 We have modules for setting something like this up. And it can be done by e.g. short-circuiting hooks unless some param is present, and so on. But a core way to do this would be most impactful. What we are missing is essentially a) a way for sites to disable request based job triggering globally (and I mean in a way that each module etc. adding these hooks doesn't have to know, e.g. $config->disableLazyCron), b) likely an option to store registered tasks in database so that they can be easily triggered and upcoming executions are made visible, and c) a way to execute scheduled tasks (something like WP-CLI cron command). Does this explain better what I meant? 🙂

CLI modules sound great, can't wait to play around with that! Two things I hope ProcessWire will eventually tackle natively (and also the things I currently think are kind of its weak points) are scheduled tasks and queues. For reference: https://laravel.com/docs/13.x/scheduling (or, pardon my french, https://developer.wordpress.org/plugins/cron/ and https://developer.wordpress.org/cli/commands/cron/) and https://laravel.com/docs/13.x/queues. I would assume that Jonathan was thinking of something similar, but I won't try to speak for him 🙂

Hey @Ivan Gretsky, that does sound like a potential bug, but I haven’t ran into it before and I know that I throw 404 exceptions from controllers time to time. I’ll try to do some testing too, but could you describe the context a bit; in what method / in what circumstances does this happen? Does it make any difference if you use wire404() instead of directly throwing 404?

Wish I had more time to put into this, but for now just a few random thoughts, sorry in advance for the long rant: I, too, do see the issues that AI is causing (or at least some of them). But this train is not easy to stop. Programming is just one area it is affecting, but in this context I am personally leaning towards the conclusion that AI may well decimate the whole concept of humans writing code for a job. And if things continue to evolve at this pace I don't think it is going to be a decades long process. A few years ago I tried to create a module for ProcessWire from scratch using ChatGPT, and it was a miserable failure. Now Claude is at a stage where I don't think I can truly justify writing code myself from a productivity (or quality) point of view. AI has also made the devops part of my work quite different from what it used to be, and I see no evidence of things slowing down in the near future. For us who work in IT and more specifically programming / development, it seems to me that in the big picture there are a couple of options: get a new job that isn't (yet) as tightly coupled with AI, or keep up with the changes. Also, I wholeheartedly agree with a lot of what Ryan has written in this thread; it's quite a bit easier to influence things positively from the inside 🙂 There will no doubt be some cases where AI is not going to be as prominent, at least for a while. But it seems to me that those are either somewhat niche, or specialized cases. Gamers and the game industry, for example, have been pushing hard against using AI, which I completely understand. ... and of course I may be wrong, and this whole thing may come crashing down any moment. Predicting the future is not easy. By the way, it would be interesting to hear about ways to make AI use less of a problem. A co-worker mentioned https://github.com/rtk-ai/rtk, which is a Rust tool that claims to reduce AI token consumption by as much as 60-90%. Someone correct me if I'm wrong, but e.g. cutting your token use to half should also cut your energy consumption to half, right? (For the record, I have not yet tested RTK properly, so can't say if it works that well.)

The more you use it, the more you’ll be blown away. At least that’s how it has gone for me and most devs I know. Since Opus 4.x, Claude has completely transformed my workflow 🙂 I enjoy “manual” coding too, but AI coding has plus sides. Going from rough idea to usable feature is blazing fast, testing and prototyping has been so much fun, and AI tends to find issue (and opportunities!) humans would never spot. Also with Claude taking some of the load off my shoulders I often find myself working on multiple things at the same time… though I guess not everyone will see that as a good thing 🫣 Oh, and docs and tests! Claude is great for that stuff. It needs human guidance for both, though, as it tends to get confused about what actually matters. AI docs are often easy to spot: many words, little (or no) meaning. Admittedly sometimes this way of doing things tends to feel less like coding and more like managing a team of skilful but a little naive devs that often need help with ideation, architecture, testing, and just plain common sense 😅

Interesting. I tend to handle Repeater Matrix items with /site/templates/fields/ files, so not sure if I've actually attempted this 🙂 If you're doing this in the context of another page, one option might be using Wireframe::page(). I seem to recall having used it for rendering Repeaters. Though not sure if that's exactly what you're looking for here?

In my opinion this would be a good idea. I get that the idea was to have an easily themeable look. That's a good goal. But — again, in my opinion — real world use cases are pretty much bound to bring in situations where more specificity is required, so we may have some work to do to find the sweet spot between control and simplicity. (By the way, I am not dismissing Bernhard's worries or the points he's made. I'm not particularly familiar with Uikit, so can't say if e.g. aligning our new CSS variables more with the variables it has would make sense or be feasible.)

Yes, variables can be changed in a specific scope. That being said, I was also uncertain whether utilizing this was a good idea, or recommended. Mainly as it seems that it might be prone to cause issues at some point in the future. To demonstrate, take this for an example (even if it was not used with variables specifically in the context of this thread): .PageList .PageListItem .PageListAction > li > a:hover That is a rather specific selector. If at some point in the future we needed to add an extra level of markup between ".PageListActions" and "li", or wrap the "a" tag in a "span" tag, etc. that would break styles relying on this selector. (Yes, it's just CSS, but that would still be an undesired outcome.) This is a benefit of having more, and more specific, CSS variables as well: if there was a --page-list-actions-link-hover-brightness variable, it would feel safe to use that. At the very least it would be less likely that someone decided to remove support for it from the admin style, as they would see right away that it will likely cause issues. (And no, I am NOT suggesting that we need to go to this level with our variables; just using this as a hypothetical example!) The point I'm trying to make here is that if this is what we are suggesting and/or recommending users to do, then we should be very, very mindful of making any structural changes in the admin. This may already be the case, so perhaps I'm just stating the obvious 🙂 If not making changes to structures in the admin seems unreasonable, one option might be to define "safe contexts", kind of like hooks for CSS variables — i.e. add a list of IDs or classes that "will not be changed or removed, no matter what". Things like "#pw-masthead", or "#pw-masthead .pw-search-form" from Ryan's examples, or ".pw-dropdown-menu" from Diogo's reply 🤷‍♂️

It's somewhat experimental (never got to use it much), but for SearchEngine there is also an add-on for indexing file contents (plain text, PDF, and most "office formats"): https://github.com/teppokoivula/SearchEngineFileIndexer. Honestly not sure how well it works at the moment 🙂

Sorry for taking so long to respond; completely missed this message. The toolbar should appear in edit mode, just as it did before. This sounds like you might be getting redirected instead of the modal window opening. I actually just fixed an issue that might have caused this in some cases (DOM was loaded before AdminBar scripts ran), but not sure if it's the same issue you were observing. Please let me know if you're still experiencing this in AdminBar 2.9.5 🙏

This button (#submit_save_copy) is added by ProcessWire, but not when viewing the page editor in modal mode, which is what we're seeing when editing a page in AdminBar. I have added an experimental option for displaying it in the modal view as well; it's slightly hidden under the collapsed "experimental features" fieldset in AdminBar configuration screen. What I'm doing is essentially duplicating the admin theme "head button" behaviour in AdminBar code; that seems like the cleanest option, as core code won't run if body has "modal" class and removing it seems like it could potentially cause unexpected side effects. Feel free to give it a try and let me know if you run into any issues 🙂

User Restrictions is a module that can — currently, I do have some future additions in mind — be used to restrict admin access for users so that requests must come from a specific list of allowed IP addresses, or alternatively must match a set of geolocation rules. For geolocation I've been using ipgeolocation.io, which is a paid service, but they do provide a free developer access. Configuration is handled via $config->UserRestrictions: $config->UserRestrictions = [ // by default restrictions are enabled when debug mode is off // 'login_restriction_enabled' => ..., // define users that are restricted 'login_restriction_enabled_for' => [ // 'my_admin_username' or 'user:my_admin_user' (username) // 41 or 'user:41' (user ID) // 'role:superuser' (role) // 'regex:/.*/' (regex pattern, which is matched against username) ], // list of valid IP addresses 'valid_ip_addresses' => [], // list of valid geolocations 'valid_geolocations' => [], // geolocation API settings (optional, required only if valid geolocations are specified 'geolocation_api_url' => 'https://api.ipgeolocation.io/v2/ipgeo?apiKey={api_key}&ip={ip}', 'geolocation_api_key' => '', // error display and logging behaviour 'display_errors' => false, 'log_errors' => true, ]; This module is somewhat experimental at the moment, so please tread carefully. Let me know if you run into any issues, or have any suggestions/ideas for the module 🙂 https://github.com/teppokoivula/UserRestrictions https://packagist.org/packages/teppokoivula/user-restrictions

This module is very much work in progress, but I wanted to get it out as soon as it is somewhat useful, so here we go: say hi to Cookie Table. Cookie Table is essentially a module for managing a list of cookies used on a site. At least around here in Finland it is a necessity to have a list of cookies, regardless of whether they are ones that you need a specific permission for. This list should include key details about each cookie, including name, purpose, and duration. Cookie Table is used to manage this data in the admin, and once you've set up a list of cookies, you can render it on the front-end as a table: echo $modules->get('CookieTable')->render(); ... or using your own custom markup: $cookies = $modules->get('CookieTable')->getCookies(); foreach ($cookies as $cookie) { echo "Cookie name: " . $cookie['name'] . "<br>"; } Now, the reason I'm saying that it's a work in progress — even though it does what I've outlined above — is that there are a lot of things I want to add still. At the moment it is mostly a tool for managing some data in the admin, which is something you could just as easily do via pages, or even simple CKEditor / TinyMCE field. What I am mostly interested is adding some automation: Crawling the site, or at least most important pages, and automatically detecting used cookies Integrating the module in whatever way makes most sense with PrivacyWire Integrating the module with existing cookie databases Adding some way to push/pull updates via web API Once one or more of aforementioned features have been added, I can definitely say that this module is worth its weight 😉 Cookie Table on GitHub Install via Composer: composer require teppokoivula/cookie-table

In my last post I said that I don't know what output strategy you are using, but from this I would assume that you are actually using RockFrontend. And thus that templating language you are using is probably Latte. To be honest I have no idea how you would do this in a RockFrontend-native way, but "AJAX endpoints" sound like a potential answer. Personally I would probably just go with an URL hook in this case, as it is pretty much "universal" for any ProcessWire site, regardless of what output strategy they are using. Gave my example in above post a quick try and it seems to work fine. URL hooks are awesome 🙂

@protro, this is an area where it is very difficult to give exact answers, but I'll try. Now, the reason I can't give 100% solid answer is that I don't know what kind of output strategy you are using, etc. And from your example I can see that you are using some templating language, which potentially complicates things a bit. The gist of it is that $searchengine->renderResultsJSON() won't remove page markup, it will just render JSON blob. If you were using a plain "direct output" output strategy, sample code could look something like this: <?php namespace ProcessWire; // /site/templates/search.php if ($config->ajax) { // AJAX request, send JSON header, output JSON and exit header('Content-Type: application/json; charset=utf-8'); echo $modules->get('SearchEngine')->renderResultsJSON(); exit; } ?> <html> <body> <!-- This is your normal HTML output --> <?= $modules->get('SearchEngine')->renderResults() ?> </body> </html> How to apply this to your particular site / output structure depends 🙂 In some cases it could be easier to implement this as a separate endpoint, e.g. using URL hooks. Perhaps something like this: <?php namespace ProcessWire; // /site/init.php or /site/ready.php $wire->addHook('/json/search/', function($event) { header('Content-Type: application/json; charset=utf-8'); return wire()->modules->get('SearchEngine')->renderResultsJSON(); }); In this case you would modify the code so that it sends JS fetch requests to this URL instead. Note: not tested, written in browser, may not work. But that's the general idea.

Same thing here, though so far only seen it on one site. Not sure if it was an isolated issue or if it just hasn't come up yet on other sites 🙂

HTMX is definitely a good solution for this! Just a minor note, even though I do get that this was meant as a rough example: be sure to always sanitize user provided input before output 🙂 <p>There were no search results for "<?=$sanitizer->entities1($input->get->q)?>"</p> As an alternative to rendering HTML in the backend, SearchEngine provides an option to output JSON, but that way you'll have to write a bit more JS. Querying data with fetch is easy, but you'll also need to rende results, handle debouncing, etc. I've been thinking of adding a prebuilt solution for that into the module itself. In the meantime here's a gist that shows one ajax search approach — just hacked it together quickly, so there are likely things that I've forgot to account for, but it seems to work based on a quick test on one of my sites 🙂

Same! I was literally just yesterday working on some content in the admin and found myself whacking the escape key to close a modal. Did not work 🙊

Public facing part of the site is no doubt the one with biggest impact, and it's also where accessibility is most commonly a requirement, legal or otherwise. That being said, I have also come across cases where same requirements have applied to the admin interface. I would say that it is somewhat rare requirement (sadly — in my opinion it should really be more common requirement) but not unheard of. This also depends on what you're doing in the admin: at least some are building entire applications in the admin, which often means that there is a more varied user base, which in turn means that accessibility tends to come up more often. For an example in one project I was able to navigate around this issue by building a separate custom admin section in the front-end for the most critical features; not really something I would prefer to do 🙂 It is true that application type interfaces are more complex to do in accessible manner. Drag and drop, notifications, and editor interfaces are good examples of things that can get a bit more involved. Drag and drop is a good example, as one essentially needs to implement two methods of operation: Anyway, long story short: I for one am not suggesting that we overhaul entire admin interface to be accessible in one huge step. That would not be feasible. One step at a time 🙂

"Low contrast, but not too low contrast" is one solution, while sometimes it may make sense to try to figure out an alternative approach entirely; e.g. instead of making something hard to see / low contrast you might consider hiding it behind a toggle, etc. (Perhaps not the best example, but that's the first thing that came to mind.) Overall this is an interesting point because I definitely get what you're saying, but at the same time being able to read text is a pretty big deal in terms of accessibility. And it's also one that can be considered a low hanging fruit: identifying contrast issues is easy, and it's usually an easy fix. As a general rule of thumb if a piece of text is worth being there, it should probably be visible to all users, and that means it should have enough contrast 🙂 If you'd like to get a better grasp of these things, I would recommend checking out browser extensions such as WAVE Evaluation Tool, or Accessibility Insights from Microsoft. Both have automatic tests that are super easy to use; while they may raise some false positives and may not catch all issues, they will point you to the right direction.

Sorry for the delay — this method is now hookable 🙂

Looks like I've got some catching up to do here 🙊 Thanks for reporting this. It should now be fixed in the latest version of the module!

Thanks for the clarification! Still hoping that we can make some minor improvements, though. Loosely related, but I'm not sure if you've noticed that there is a are a couple of comments related to one recent admin change 🙂 That sounds a bit disheartening. I've never actually built anything from scratch with Uikit so I'm not too familiar with its structure, and I must admit that digging into AdminThemeUikit just now made my head spin, but it looks like variables are defined mostly in one place. Is that right, and if so, would it be an option to set those based on CSS variables? That might not work with — or rather stay in sync with — custom admin styles, though. Of course there's always the option of somehow duplicating LESS variables to CSS variables. This way they could at least be used in modules etc.

@bernhard, out of curiosity (and since I'm currently also testing out SSE): did you figure out why exactly this was needed? Found a Stack Overflow post that pointed to nginx docs, as in that particular case it appeared that proxy buffering was the culprit. It has by default 4K or 8K buffer size, so it would seem to make sense that sending 8K+ spaces before real value solves the issue by effectively overriding the buffer. What I'm wondering is if that was also your problem, or if there are other potential causes for this as well? Seems kind of hacky having to send (relatively speaking vast amounts of) extra data with each response 😄