BrendonKoz

I get errors like this that I cannot reproduce more often than I'd like and, because I can't reproduce them, haven't been able to track down how or why they occur. I think it's a race condition based on PHP code running faster than the filesystem (ex: the code says to create a folder, the OS tells PHP OK, code continues, but the filesystem hadn't actually completed creating the folder). When I refresh the same page, I either don't get any errors, or I get a different file/folder that throws an error. Eventually refreshing enough times clears all errors. This is all just a hunch, so changing PHP versions might cause a large refresh of many files and folders of the cache all at once, which could have a higher probability of hitting a race condition like this - if it is indeed what causes the error.

Yup, definitely possible. It can potentially cause breaks in unintended spots which, for certain languages, are just unacceptable, so that has to be considered as well. It's still an option, though. A soft hyphen or <wbr> are options that allow direct control of where breaks should occur, if any, and one must consider what is best for their project and use-case. Thanks for providing the linked resource, aagd! @BitPoet and @Alf S. thank you for reporting back!

I just tested this a bit with HTMLPurifier, and (at least in quick testing) was unable to prevent it (as far as I could tell) from removing the HTML equivalent of the character (using &shy;, or pasting a rendered version of it in directly). Searching the internet as a whole doesn't seem to give much specific information either. Since &amp; worked but &shy; did not, I'm not entirely sure what's going on internally without auditing the underlying code (for HTMLPurifier), and would likely have to do the same for CKEditor and/or ProcessWire. If you change the field from a WYSIWYG interface to a simple textarea, does it work as expected? If so, you might need a CKEditor plugin for the soft hyphen, but I'm simply guessing. In the one Stack Overflow topic I found, most people actually recommended using <wbr> over a soft hyphen - why do you feel it's "kinda outdated"? With the exception of Internet Explorer 11, it has full browser support, and if it works right now (whereas soft hyphen does not) then that's less time you'd need to worry about it. As for the lack of a hyphen, there might be some CSS solutions there, but I'm unsure how well they'd work out. One last thought: I didn't test this in ProcessWire myself -- are you sure it's not just converting the text of &shy; to \u00ad in the database?

Hello da², I still stand by my comment in that you are in compliance, a warning is not the same as an error, and attempting to circumvent the current processing of text for the sake of clearing a warning may cause more harm than good. That said, this topic came up back in October, and the linked topic should provide you with possible workarounds, if you decide to take them: EDIT: For any modules that output their own HTML (ex: InputfieldText's ___render() method), you'd need to find, and then override the module's own output method to fix; or setup and run all of your generated HTML through a post-processor.

Hey Ryan, Thanks for replying and confirming my assertions above, and also thanks for identifying your intentions of its purpose. That was what I figured it was for (primarily cleaning pasted content from other rich text editors). I could see some end-users copying and pasting from other websites, or even other owned properties of theirs and, if sharing a CSS theme, expecting a similar output. To be frank, I don't even think I would want that to work, but I wanted to test just to be sure how versatile the Pastefilter was, and what its limitations were. As for pattern matching attributes or values, I can't currently imagine a necessity for that particular use-case, and until there is one out there by someone, I don't think there's any need to even consider building it into core. Regardless, I'm pretty stoked for this additional functionality for cleaning pasted content!

Pastefilter: For someone currently testing, could you see what the difference in the Pastefilter is for a[href|id], a[target=_blank] and a[href|id|target=_blank], if any? It seems Ryan split any assignments to their own entry, even though they merge, so I was just curious if there was a reason for that, other than potentially simplified logic/understanding. Not that I currently have a reason to do this, but what if there was a need to whitelist a certain range of classes (attributes; perhaps data-* attributes)? Similar to allowing the pasting of fontawesome content? I'm thinking there's no REGEX or glob matching for attributes and associated values (ex: i[class=fa*] which should cover i.far.fa-horse, i.fas.fa-horse, etc.). Tip on Performance of Plugins: Although it makes complete sense, I might not've thought to check that. I very much appreciate the tip about that, and the "advlist" plugin, specifically! Thanks! The amount of work on documenting its behavior is extremely welcomed - thank you so much, Ryan! EDIT: Pastefilter -- I tested... It appears as though there's a specific distinction when applying value matching as opposed to simple attribute allowance. If providing a match to an attribute's value, it must (currently, at least) have its own unique entry in the list. It cannot be merged with the simpler attribute entry that allows any value. In my testing when I merged the entries together (ex: a[href|id|target=_blank]) only the matching attribute entry was allowed and retained during paste (target=_blank).

Hello Stephan! Hopefully you've scoured the forums and found similarly posed questions by now, but just in case you haven't - ProcessWire is, at its core, a solution for a CMS - a content management system. ProcessWire simply takes that concept a bit further by allowing those who use it to custom tailor the system itself. So with that very short explanation, a Content Management System is something that manages content. This means that once you've come up with a visual template, theme, or whatever you'd want to call it, the system itself is what manages everything from that point onward. Going back and forth from a development tool and using it as your page editor, and hoping that the CMS you choose will simply ingest that - if I'm understanding your use case correctly here - isn't really something that many systems can take advantage of. Theoretically I suppose that it could be used to do it, but it's a lot of work to get it to a point to where it won't realistically even be used to manage things on the site. Using any CMS for this scenario seems like overkill, where the primary content is managed by a visual HTML editor. If it's logical to you, I can't say it's wrong. I will say that it's unique! It's also likely not the best option as: You're relying on your visual HTML editor tool (Pinegrow) to produce proper HTML/CSS/JS that is accessible, and without errors -- and that will always work with whatever main template you intend to embed it into You're installing a PHP/MySQL tool which, other than perhaps for page and navigation management, isn't really being used for anything else, and the powerful functionality found elsewhere in it could not be properly used (ex: search). I think, using the scenario you've provided, the simplest way would be via a PHP include. It's hard for me to picture it all as I'd think if you went this route, it'd almost make more sense to simply manage everything within Pinegrow and just upload all changes manually. I haven't looked at it closely enough, but I think you can manage a navigational structure within Pinegrow, it's just a bit more work. It could be a problem. It all depends on how you create the pages in both systems. If you're not particularly careful with it though, then my answer here would be, "Yes, it could be a problem." Absolute vs relative links would depend on your naming conventions, templating, and internal page creation within PW and Pinegrow. What you could do is use Pinegrow to manage the website in its entirety, as you seem more familiar with that as a tool. Study up on ProcessWire and how it works (and/or other CMS/CMFs to see what might fit your ability and effort the best - flat file-based CMSs might work better for you) - and then slowly convert it to being managed by a CMS instead of Pinegrow.

Unfortunately I don't know anything about OVH. That knowledge might be needed here... If I can reach 'https://auth.giobby.com' in a web browser (GET request) without error, and you're saying that Postman works - then I would have to think everything is configured properly on the server that is handling the authentication portion of your server/code. Considering that, I'd be focusing on playwood.it to see if/why there are issues from there. You could enable debugging in your cURL call: curl_setopt($ch, CURLOPT_VERBOSE, 1); If there's an error, you can review that from your unused variable ($error), and/or check your server/php error logs. From using your code above, however, I was able to get a successfully retrieved value for access_token on my local machine's development/test server.

It seems like you could take advantage of the part of the module's documentation that I linked to above, something like the following: <?php namespace ProcessWire; $searchEngine = $modules->get('SearchEngine'); ... <head> <?= $searchEngine->renderStyles() ?> <?= $searchEngine->renderScripts() ?> </head> <body> <?php echo $searchEngine->renderForm(); // This assumes your search form uses GET, and a field named 'q' if ($q = $sanitizer->selectorValue($input->get->q)) { // Modify your value of the search query ($q) here... // ... // This finds pages matching the query string and returns them as a PageArray: $results = $pages->find('search_index%=' . $q . ', limit=25'); // Render results and pager with PageArray::render() and PageArray::renderPager(): echo $results->render(); // PageArray::render() echo $results->renderPager(); // PageArray::renderPager() // ... or you iterate over the results and render them manually: // echo "<ul>"; // foreach ($results as $result) { // echo "<li><a href='{$result->url}'>{$result->title}</a></li>"; // } // echo "</ul>"; } ?> The biggest benefit to the SearchEngine module is its creation of the (default) `search_index` field. You can query against that field just like any other field within ProcessWire. Rendering the form and search results are just additional benefits.

This might also be able to do what you're looking to do (if you want something out-of-the-box)? It's a commercial module. kongodongo's Dynamic Selects.

Just issued a simple GET request to the provided domain and it redirected (without error) to what I suspect is an expected subfolder. So...either it's working as expected now, it's an issue with your network/computer (and is working), or perhaps you're not taking into consideration URL forwarding from rewrite rules (whereas Postman likely is)?

Hi Clarity, Can you clarify what you mean by, "modify the query during search," perhaps with an example of what you are looking for? SearchEngine does provide the ability for you to not use its default ProcessWire searches, and instead simply prepare the index and form/results for you, so that you can form the query manually on your own depending on your own needs, as shown in the module page's documentation. Is that what you mean? If not, an example would be great. 🙂 Some of adrian's examples within this topic may be of use too.

This could possibly become a course all on its own, but there are often questions on how to manage navigational structures (header/footer/on-page) in ProcessWire. Covering how to (try to) plan around it, either based on the layout design, or based on the architectural design (or the client need?) are all potential topics. Sites with simple structures (and few templates) are usually fairly easy, but if you were to design a website for a university that holds many different departments all with unique needs and content, things can get quite complicated; often times there is the primary navigation, a sub-navigation (that may break into child-navigations per department), and custom footer navigation areas per section! If aimed at beginners, something that should likely be covered early on is templates/themes and ProcessWire's Site Profiles, and how unlike other solutions, downloadable site profiles contain not only the layout and design, but also the underlying architecture and fieldtypes, so switching templates is not (currently) a thing with ProcessWire. (We'd need something like WordPress' various theme builders [ex: Divi] where it's a theme framework, so the framework is the profile, and themes/templates/styles could be swapped within the framework...we just don't have that [yet?] for ProcessWire.) ...oh, and also that files and images are associated to the pages they were uploaded to (instead of a centralized media manager, unless one is setup [through a page] in your magazine website example). Also of note, and this took me awhile too: It's "ProcessWire", not "Processwire". 😅 I'd probably sign up just because I enjoy taking courses. You can always learn something new. Video courses are a lot of work (to keep updated) so I wish you the best of luck on this!

After adding my larger RepeaterMatrix field to the indexed_fields, on my first page save test, I seem to be running into a warning at line 315 of /lib/Indexer.php, "foreach() argument must be of type array|object, null given". I'm not sure why it's detecting the value as null... I'm not sure what I'm doing wrong here. Any thoughts? For reference, the snippet of code for this method is below: <?php protected function ___getRepeatableIndexValue(\Processwire\Page $page, \ProcessWire\Field $field, array $indexed_fields = [], string $prefix = ''): array { $index = []; $index_num = 0; $prefixes = $this->getOptions()['prefixes']; foreach ($page->get($field->name) as $child) { At this moment within the loop, the value of the referenced parameters are: $page = \ProcessWire\RepeaterMatrixPage ... it's forPage attribute is null (perhaps that's why?) but its forField value is my primary repeater field: $content_body $field = \ProcessWire\RepeaterField ... this field, `faqs` is itself a repeater (not matrix) field, which contains a combo field (faq), which has attribute names "question" (text), and "answer" (CKEditor) I believe I have all relevant fields added to the indexed fields selection for SearchEngine within this context: content_body, faqs, and faq. Does SearchEngine support RepeaterMatrix (and/or Repeater) fields with multiple levels of depth? ADDENDUM: I just noticed that on this particular page I'm saving (as a test with these fields added), the RepeaterMatrix doesn't allow the use of faqs (it's a template-based override), nor are there any faqs in the content of the page.

Hi teppo, although I believe this request may be more related to the core module (SearchEngine), I'm thinking that the question might belong here. Apologies if that's confusing! First off - in my limited testing, for files that contain properly stored textual data, this has worked as great as can be expected (based on the capability of the vendor classes). Thank you! My thought here, however, is that if a search result was a hit due to it being a match to contents of a file, the expectation would likely be that the file would end up getting listed as a search result (link). Currently due to how SearchEngine (and ultimately ProcessWire) works, the resultant link is for the page that a file resides on. Since there may be circumstances where many multiples of files exist on a page, or are somewhat hidden, would it be possible to link directly to the matched file instead of the owning page? Random thoughts on this, not sure if it's on the right path or not...: SearchEngineFileIndexer has a configurable option to create separate (database level) index_field entry (or custom-named) field entries specific to the files/images rather than the page (or both, or only the page [default]), and similarly to SearchEngine, what to use as the result_summary_field. This would likely require an alteration to the schema of the index_field from the SearchEngine module, such as, if a file/image, its a column for its path (and if no path, we know it's not a file/image but a standard page). SearchEngine would then, if detecting the extra field in the database, optionally provide a direct link to the file instead of the owning page's URL. Similarly, it may (in certain places) pass along an is_file attribute since I don't know if AJAX-based searches for auto-suggest might want file matching results to show up in all situations (and that could be one way for the developer to prevent it).

I'd like to say that although it might've been easier on the developer (and more like PW field template rendering) to allow a single HTML-esque template file for overriding the default templating, I very much appreciate the ability to create our own custom arguments within the config's `render_args` array. It made it easier to customize my own template (which used additional elements and attributes) while still offering me to create, additionally named, custom keys in the multidimensional array! Because of that, looking back at my custom template file config it should make more sense what property is controlling what area of the template strings within the form. The only thing that I felt silly about was not realizing the `minified_resources` was a boolean setting in the config and not an automatic check via the filesystem. I prefer how it is configured as opposed to what I thought it was doing, but I didn't realize it at first. Oops! An excellent module - thanks, teppo! Questions: I'm going to continue investigating, but...is it possible to access a search result page object? I'd like to render the breadcrumb per search result, but I'm not (yet?) seeing how to access the returned $page properties from the find operation within the templates. I think I'll likely need to use a hook for this but haven't yet dived that far into things. [EDIT: Okay, looks like I hook into renderResult.] Can the `limit` setting value be made to allow the theme config to override? It seems I currently have to set this on the site config level. The below snippet was not working for me. $theme_args = [ 'find_args' => [ 'limit' => 10, ], 'theme_styles' => [], 'render_args' => [...] ]; EDIT: Thanks to adrian I now see I can manually pass in the limit value by calling `find()` and passing in a query object. It might be easier to simply offer `limit` within the theme config, but at least for now, this is also just as easy. 🙂 In fact it might be easier since one doesn't have to worry about the SearchEngine theme and can just handle it in their template file. $searchEngine = $modules->get('SearchEngine'); $findOptions = ['limit' => 25]; $query = $searchEngine->find($sanitizer->selectorValue($input->get->q), $findOptions); $searchEngine->renderResults($renderOptions, $query);

I'll have to do some more investigating as to why, but currently for whatever reason my favicon isn't properly rendering. I'm instead getting a default error image of the web globe, whereas another SVG image worked as expected. If I figure it out I'll post back. That said, I think this idea is an excellent one, a fairly simple addition, and one that I think could be added to core. EDIT: For whatever reason, I ran it through a PHP urldecode, then re-urlencode'd it; the issue seemed to be with the hash symbol for the fill color not being encoded... (Though if part of the core, it could simply link to a core file, via an auto-generated redirect/include from a site file in admin.php which would be easier [to customize and/or load], and be cacheable). wire('adminTheme')->addExtraMarkup('head', "<link type=\"image/svg+xml\" rel=\"shortcut icon\" href=\"data:image/svg+xml,%3Csvg width='256' height='256' viewBox='0 0 256 256' xmlns='http://www.w3.org/2000/svg'%3E%3Cpath fill='%23EB1D61' fill-rule='nonzero' d='M234.02346,56.2065308 C226.258185,44.611679 213.340949,31.3634673 200.370381,22.7873303 C173.426584,4.33370224 142.216153,-2.21573572 114.611028,0.642976614 C85.8219124,3.7470262 61.1714319,14.5951995 40.9049183,32.6861551 C22.1317268,49.454423 9.73715371,69.9560838 4.27586162,89.5083961 C-1.24942998,109.060708 -0.513435538,127.162331 1.45988289,140.794549 C3.53986718,154.629436 10.4304818,172.037714 10.4304818,172.037714 C11.8384712,175.376434 13.7904564,176.731123 14.8037821,177.296465 C19.8384108,180.048509 28.105015,177.627137 34.4516337,170.50169 C34.7716313,170.06435 34.9422967,169.45634 34.7716313,168.944332 C33.000978,162.128223 32.3609828,156.997474 31.7316543,153.029411 C30.2916651,145.178619 29.65167,132.026409 30.6116627,119.866214 C31.0916591,113.284776 32.3716494,106.244663 34.6116325,98.8632122 C38.9422665,84.281646 48.0728642,69.0600695 62.3447564,56.4092007 C77.715307,42.7876498 97.4271581,34.3715154 116.16835,32.1954806 C122.738967,31.4061347 135.240206,30.6487893 150.290759,34.3608485 C153.501401,35.1608613 167.282631,38.7555854 182.023853,48.7397449 C192.754438,56.0358614 201.394373,65.0386719 207.346328,73.9454809 C213.404949,82.44695 219.986232,96.783179 221.916885,107.279347 C224.647531,119.226204 224.647531,131.88774 222.706212,144.218603 C220.30623,156.570801 215.975596,168.581659 209.24498,179.152495 C204.605015,187.344626 194.983755,198.171465 183.613174,206.299595 C173.362585,213.510377 161.66134,218.715793 149.650764,221.595839 C143.57081,223.035862 137.469522,223.95321 131.218903,224.15588 C125.661612,224.32655 118.291001,224.15588 113.117706,223.2812 C105.427098,222.054513 103.82711,220.091815 102.067123,217.425106 C102.067123,217.425106 100.840466,215.505075 100.499135,210.36366 C100.616467,163.376243 100.595134,175.920443 100.595134,151.525387 C100.595134,144.63461 100.371136,138.383844 100.435135,132.709086 C100.755133,123.396937 101.54446,116.996835 108.20041,110.063391 C113.01104,104.953976 119.741656,101.87126 127.154934,101.87126 C129.405583,101.87126 137.160191,101.977929 143.97614,107.642019 C151.282751,113.74345 152.509409,122.084916 152.797407,124.314285 C154.461394,137.359827 145.842792,147.077316 142.536151,149.541355 C138.440182,152.613404 134.760209,154.106761 132.274895,154.981442 C126.984268,156.752137 121.170979,157.264145 115.944352,156.922806 C115.144358,156.869472 114.41903,157.392147 114.259031,158.19216 L112.499044,167.322972 C110.781724,174.256417 114.632361,176.795124 116.872345,177.691138 C124.029624,179.899173 130.376243,180.816521 137.896186,180.251179 C149.426765,179.440499 160.797346,174.896427 170.450607,165.893616 C178.663878,158.085492 183.346509,148.453338 184.946497,137.679832 C186.546485,125.722308 184.466501,112.847436 179.015875,101.945928 C173.021254,89.9244028 162.674665,79.8869091 149.042768,74.393488 C135.272206,68.9747348 124.317622,68.7827317 110.195062,72.3881226 L110.035063,72.4414568 C100.861799,75.5988406 93.0111915,79.4922361 84.8405865,87.9297042 C79.2406288,93.7537973 74.6539968,100.804577 71.8593512,108.762037 C69.0860388,116.783498 68.3393778,122.767594 68.2113788,132.069076 C68.0407134,138.959853 68.3713775,145.359955 68.3713775,151.354717 L68.3713775,190.832681 C68.3713775,203.462216 67.9447141,205.648918 68.3713775,212.145022 C68.6060424,216.454424 69.2033713,221.329168 71.091357,226.566585 C73.0326757,232.337344 77.1073116,238.257439 79.9019571,240.988149 C83.8165942,245.158882 88.7978899,248.508269 93.693853,250.588302 C104.904435,255.569715 120.125653,256.359061 132.466893,255.879054 C140.637498,255.569715 148.85077,254.439031 156.904042,252.529667 C173.010587,248.700272 188.477137,241.734828 202.077034,232.070673 C216.658258,221.798509 229.330162,207.782285 236.327442,195.878095 C245.298041,181.733869 251.100664,165.861616 254.119308,149.552022 C256.839287,133.210428 256.711288,116.452827 253.063316,100.356569 C250.183338,85.4229975 242.492729,69.0387358 233.61813,55.8118579 L234.02346,56.2065308 Z'%3E%3C/path%3E%3C/svg%3E\">");

Unfortunately from discussions I've seen, it's either unlikely that HTMLPurifier will be implementing a supported HTML5 Doctype, or it will be quite awhile before one arrives. They're taking contributions, but the amount of work (and surrounding understanding) seems daunting. The removal of unsupported elements would be part of the unforeseen consequences I mentioned. I'd still recommend using a call to str_replace instead if you do decide to stick with this. That said, using <br/> or <br /> is not invalid, and is allowed. You're seeing info messages in the W3C validator service, not notices or warning messages. It's because HTML5 doesn't require (like XHTML did) that element attribute values are contained within quoted strings, and if an element using unquoted values ended with a trailing slash and no word boundary, it could cause confusion in the browser. See their example for more info: https://github.com/validator/validator/wiki/Markup-»-Void-elements#trailing-slashes-directly-preceded-by-unquoted-attribute-values This was a great exercise in how to customize the HTMLPurifier and CKEditor components, but I'd personally recommend, at least in this instance, not making that change. That said, it's completely up to you, and you have a working solution for your target goal now!

Using the HTMLPurifier demo page, if you change the defined Doctype to either of the standard HTML Doctypes, the BR tag will not use the XHTML formatted version. That said, there may be other unforeseen consequences in making this change. If this is simply an aesthetic preference, I would personally recommend leaving it alone. If there's another reason for it, I'm thinking that a call to str_replace on your data would be far simpler. If you do decide to customize HTMLPurifier, a good place to start for examples would be here and here. Here's an example set call that would change the Doctype to HTML Transitional, adjusted from the PW API Documentation example: $wireData = $markupHTMLPurifier->set('HTML.Doctype', 'HTML 4.01 Transitional');

I'm familiar with (a little bit about) container queries, but I haven't seen anything that would offer up automatic negotiation to forcibly size an unknown amount of text into a statically sized container without overflow. Thanks though! Lots of nice things coming to us via CSS, for sure. I haven't seen anything either, though since Tailwind seems to take advantage of CSS and JS, I wasn't sure if they might've solved this too. ? I've used fitty for a headline in one of the aforementioned slides already, though (at the time) it did have a few limitations. I see it's still getting updates, I'll have to look it over again. Thanks!!! I realize I kind of sidetracked the conversation on a bit of a tangent. Sorry! Overall this is a great topic though, Bernard!

@flydev ?? Can that be used in a way to make sure text fits within a box that is static and pixel-sized? Scenario: I develop HTML-based "slides" for monitors in a building, used for marketing purposes (ex: fast-food restaurant screens) which has a known, defined size (1920x1080). Because of that, I don't worry too much about responsiveness of containers. What would be awesome, however, is making sure text is sized to forcibly fit within a contained-size container without overflow -- and an unknown amount of text. I've not found many good solutions to this. I also haven't dived into Tailwind, so am unfamiliar with what it provides in that area, if anything.

I'll try to spare you from the, "Why would you want to [...]" question, as there are any various reasons why someone would want/need to migrate one way or another. Because ProcessWire is a Content Management Framework that helps a developer create a Content Management System, it's so varied in how it could be created that it might not be a simple export and re-import. Custom tools might need to be built -- or you might be lucky if the site is simple enough, you could potentially take advantage of something like the Import/Export modules, but those are often purpose-built for singular purposes as well. With few exceptions, all content should be in the template files and in the database. With some properly crafted SQL queries, you could get the data that you need. You could then rearrange those SQL queries as an insert into WordPress -- or convert it into a format that WordPress has an importer for. If this is your website though, it looks fairly custom with page partials used to build out the full page. If you're not a developer, you might need the direct help of a developer.

Personal opinion: I think if I were to make a decision on what I see about Payload, I'd probably (personally) opt for Statamic for two reasons: I'm more familiar with PHP, and since it's a file based CMS and can be run directly from a Git repository, it makes things simpler (even if the installation is, IMHO, ridiculously bloated: thanks Laravel). I see some level of inspiration in it by Statamic, Kirby, and maybe Wagtail, but obviously with its own take on it all. For Directus: I don't personally see that as a CMS - or at least CMS-first option. If I remember correctly (I might not), it was originally advertised as a visual data query builder, enabling the ability to connect to an absurdly large amount of disparate datastore solutions, and then (visually) build queries to concoct interfaces and/or reports related to that data. Can you build a CMS with it? Apparently so! Should you build a CMS with it? I suppose that depends on exactly what it offers. I haven't personally tried it, even though I've kept my eye on it in case I had a project that seemed to fit. So far I (unfortunately) haven't. (I kind of want to play with it. It looks ridiculously powerful.) All that said, I haven't tried either, so my involvement isn't exactly what you were hoping for. As far as RestAPI and GraphQL, are the related modules insufficient? (I know you said default modules, so my curiosity is only adjacently related.) I definitely enjoy comparing and re-evaluating tools though, so appreciate this hashed, and rehashed, and rehashed topic! ?

@dragan Absolutely excellent feedback. I'll need to take this all in and review it in more detail -- and as you suggest, run it through some screen readers. I'm completely unfamiliar with aria-live aspects, and (unfortunately) only mildly aware of aria itself. What I need is to take a course on accessibility. Reading about it is one thing - seeing it in practice and understanding it is another. ♥️ I definitely want to do better. What you're playing with above in the example is a static HTML mockup template, prior to ProcessWire integration. Although the interface is pretty much the same at the moment, it will divert as development continues, so if I do improve things, it won't be visible!

Thanks, dragan! I very much appreciate you sharing what you know of accessibility in this regard. When I researched this, I specifically looked for guidelines related to "maps", interactive or otherwise. I figured with the number of shopping malls around the world, surely someone would've been sued a large enough amount of money to end up being forced to determine best practices. Unfortunately I was wrong. There isn't much out there aside from providing a text-based alternative, an audio-alternative for the text (if feasible), and high contrast colors and large text. I'll admit I can work on the high contrast, though that can come with a CSS media override via browser setting detection, though I still need to write those style overrides (and fix up my dark mode styles). From your two examples, I went the hidden DL (DT / DD) element route -- that's where the directions (on how to get to/find) related to each of the entered items within the repeater get rendered straight to HTML. I need to review the DL's aria attributes though, so thank you for the reminder! I haven't hidden the SVG via ARIA, but still need to think if that's the best decision here (it likely is). I'll also look over the CSS-Tricks article since it's more SVG specific and likely why I didn't see it. I'd be curious to see how simple it might be to implement into my SVG implementation. When I was looking, I read through things like these: Digital Maps & Accessibility Accessible Maps The first one mentions pointing out accessible parking and highlighting drop-offs and ramp access which I either forgot about, or this wasn't an article I read before (but instead was very similar). I'll have to add some supplements to this relating to outdoor access. The second one, from the W3C basically says that there aren't any guidelines because the level of detail in a map is too high, and the needs of the map and the person vary too much to directly identify any set rules (paraphrased).