teppo

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 🙂