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 🙂

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 😄

Hey Ryan! First of all, this all sounds very promising. In my humble opinion you are vastly underplaying your own skill in terms of design, but that's also why we can trust that you'll recognize amazing design once you see it. Looking forward to seeing what the team working on the design has cooked up 😉 Now, please forgive me for jumping directly into asking for stuff, but... I know this is small thing, but it would be quite nice if the new admin made use of CSS variables wherever it makes sense; colors, font sizing, etc. (Or provided them as an alternative for non-core tools to use, in case it is not feasible to use them for actual admin styling.) The reason I'm saying this is that I've built various admin tools that I wanted to look like the admin theme, and since there is (to my knowledge) currently no simple way to access existing colors etc. in CSS, any non-Uikit elements I've had to "hard-code" to use current styles. This includes the default green/cyan/blue color theme, current spacing and font size practices, etc. As a result said custom elements may look out of place once the theme is updated 🙂 (Just for the record: SCSS/LESS might be an option, but that feels like a lot of unnecessary overhead and complexity where vanilla CSS would easily suffice. I'd really like to avoid that if possible, and to me it seems like CSS variables are an easy and well supported alternative.) Additionally: it would be awesome if accessibility was a consideration while creating this new admin theme. I know it has been considered to a point in the past, but has never been a major goal. Hopefully we can push things forward in this regard in the future. If there's something I can help, I'd be happy to 🙏

Thanks, I’ll look into this soon. I’m using MariaDB almost exclusively, and it seems that this is not an issue there. There seems to be one potential gotcha with the suggested solution: https://stackoverflow.com/questions/45494/mysql-error-1093-cant-specify-target-table-for-update-in-from-clause. Might be better to do two queries instead.

At this point it's a bit hard to put myself in the shoes of someone just getting here, but some highlights from the top of my head: The community is awesome 🙂 The ability to define and modify data structures in the admin using an easy-to-use GUI is still a huge deal. One can quite literally create a full-blown application just by clicking around the admin, especially when combining it with something like ListerPro (though that's a commercial tool, so may be a bit off scope here). Even for those with zero programming know-how, getting a simple ProcessWire powered site (or app) up and running is a (relatively) easy task. Selector engine makes querying data extremely easy, and selectors also scale exceptionally well for complex needs. Most beginners are unlikely to need to know how sub-selectors or OR groups or more complex operator types work, but there is a lot of flexibility hidden underneath. For those that have worked (or fought) with WP_Query, our selector engine is a major selling point. Right out of the box there's a lot of stuff there that even some of the most advanced content management systems don't have — custom content types, amazing language support, numerous field types and inputfields, etc. Honestly, the language support alone is more advanced than anything I've seen in other systems so far, with or without plugins. While it's impossible to compete in numbers with WP, there are actually a lot of high quality modules for ProcessWire. One probably won't be able to carve out a custom application just by slapping modules on top of modules, but there's a whole lot of stuff that they can do. Once you're familiar with the system, extending it with modules and/or hooks is easy. Did I mention the community? Also, ProcessWire is open source and free to use with no strings attached. Unlike some other systems. (Sorry, had to go there.)

It's possible that I'm still missing the point, but if the underlying problem is that there are multiple data sources with differing data formats, there are only two top level approaches that I can think of: write a separate import script / profile / configuration for each data source, or write an adapter per source that converts them to single, uniform format, which you can then import. For me personally scraping is never the preferred option, as it comes with a number of potential issues. For one you may not be able to scrape all relevant data, or you may get malformed or partial data — and you may not know it before it is too late. Getting your hands on the raw data is almost always much, much better. At the very least I would contact each vendor before scraping to confirm that a) they think it is doable and b) it won't result in them blocking you due to your scraping tool exceeding rate limits etc. If you can't make sense of the data format you've got, ask for some kind of documentation. The worst case is that you need to figure things out on your own — that can easily lead to nasty issues, as your assumptions could be completely wrong. If there is no way to get solid documentation for the data, let your client know that it's essentially a guessing game at this point. Especially when money is involved that's not a great situation to be in. Anyway, from what I've heard so far this all seems completely doable, but could obviously get pretty time consuming — and hence costly 🙂

https://github.com/teppokoivula/ImportTool was built to handle a similar need, in case you want to check it out. It’s most useful for imports that may be needed again later, though; the idea is that you define an import profile, which can then be executed via the admin while also providing an input file for the data. Depending on the data I usually set limit somewhere between 50-500 pages and set the “on_duplicate” setting for the profile to “continue”. This way you can keep running the same import profile with the same data file until you’re done. This module is a bit unpolished, but in use on a few of our sites 🙂

@Ivan Gretsky, this feature is now in master branch (0.31.0). Though please test a bit before putting it in action 🙂 Regarding this, I gave it a bit of thought and added something that I hope makes sense to you: if the view prefix value has exclamation mark as a suffix, e.g. "!theme/", it will be considered a strict value. If that's the case, the exclamation mark is automatically stripped from the view prefix, and in case a view file with the prefix can't be found, Wireframe should act like it didn't find a file at all. I'm definitely open to revisiting and/or tweaking this behaviour. My motivation here was mainly to a) find a solution that feels intuitive without introducing too much complexity, and b) preferably avoid adding more configuration flags. I didn't really have a lot of time to test the latest changes yet; hopefully I got them right, but please let me know if I've caused any new issues 🙂

Good question. Version Control is not currently under active development, but not abandoned either. For an example if anyone wants to contribute, I’m always happy to go through pull requests 🙂 I don’t currently have much use for this module myself, and it’s a bit of a beast so working on it tends to be time consuming. Not a great combination. That being said, I’ll add a reminder to get back to the posts in this thread as soon as possible. Notifications are not working so well for me, and I’m pretty awful at checking module support threads manually.