BrendonKoz

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).

I should've put this topic into the Dev Talk forum section; my mistake! If a moderator wants to move it, by all means... ? I'm sure this isn't the most elegant way to do this, but it's what I came up with in the time I had. I ended up using a (ProField) Combo Field (see attached image for schema) to store each individual object's attributes that I wanted to have some level of editability within the CMS, and then stored those in a simple Repeater field as part of the "floorplan" template. I'll lock down the class_name, class_addition, and svg_path fields to administrator level accounts as they will be maintained in a much more fragile way. I used a Pages::saveReady hook in ready.php to detect changes on the repeater template (all repeaters have a hidden system template) in order to read in a version of the floor plan SVG that had valid, but easily identifiable XML strings to be used for (dynamic) replacement - and then write out a modified version using said replacement. An example of that string is below -- the floor number is the only thing that differs between each {placeholder}-esque string. <g id="floor0_fill"></g> The hook would then loop through all of the data provided in each combo field to generate the layers as needed, and then save the new version of the SVG file, completed as expected. I'll provide the code below, but it's only intended as an example for what I did. // Floor plan page - dynamically generate the static SVG from a template, and saved page fields' data $wire->addHookBefore('Pages::saveReady', function(HookEvent $event) { // Get values of arguments sent to hook (and optionally modify them) $page = $event->arguments(0); if ($page->template != 'floorplan') return; // Only process if the content of the floorplan items has changed $changes = $page->getChanges(true); if (!isset($changes['floorplan_repeater'])) return; // Generate the individual item SVG element entries $repeater = $page->floorplan_repeater; $svg = []; foreach ($repeater as $item) { $name = $item->floorplan_item->name; $type = implode(' ', $item->floorplan_item->type); $path = str_replace("\n", "\n\t\t\t\t", $item->floorplan_item->svg_path); $level = $item->floorplan_item->level - 1; // fix offset as set from PW ComboField's Select type $class = $item->floorplan_item->class_name; $full_class = $item->floorplan_item->class_addition ? "{$class} {$item->floorplan_item->class_addition}" : $class; $svg[$level][] = " <g id='floor{$level}_{$class}' class='{$type} {$full_class}'> <a class='item' xlink:href='#content-skip'> {$path} <desc>{$name}</desc> <text class='label' x='40' y='70'>{$name}</text> </a> </g>"; } // Open the SVG template (floorplan-template.svg), replace the content where needed, and save to the final SVG file (floorplan.svg) $path = $this->wire()->config->path('templates') . 'svgs/'; $svg_template = $this->wire('files')->fileGetContents("{$path}floorplan-template.svg"); if ($svg_template === false) { $this->error("The SVG template file could not be found: \"{$path}floorplan-template.svg\"", Notice::log); return; } foreach ($svg as $index => $floor) { $svg_template = str_replace('<g id="floor'.$index.'_fill"></g>', implode("\n", $floor), $svg_template); } $this->wire('files')->filePutContents($path.'floorplan.svg', $svg_template); }); It took me quite some time to find the proper way to identify a file path in ready.php!! That alone might be useful to someone. PW's filePutContents method (which also sets chmod) needed a path formatted in a specific way before it would work, and I wanted to do it the PW way, rather than the standard PHP way. Anyway, moving on... At this point all of the data was in the database, the SVG was generated dynamically from a template, and I moved on to dynamically generating the hidden definition list elements (that provide directions to each selectable object on the map, per floor), and the form elements that filter which map object is being highlighted on the map (with directions) at any given time. Lots of class/id/data massaging trickery, for sure! ...like the one below which was especially fun (and extremely ugly code). // Example Output: <span class="badge">G</span> <span class="badge">2</span> // Example Input: [0 => 'ground', 2 => 'two'] $badges = '<span class="badge">' . implode('</span> <span class="badge">', explode(',', str_replace('0', 'G', implode(',',array_keys($properties['floors']))))) . '</span> '; ? It's all working as of today, I only have some cleanup and optimizations to do - and the staff have just decided to do major furniture changes. ?‍♂️ At least the coding part is done! Back to the drawing board on the Illustrator file though!

Hi @Robin S, and thank you for the reply! That's a good workaround. I was too focused on the oddity to even consider that. That said, in your opinion, do you think it is fairly safe to say that the limitation exists? I don't know if it's a bug, per se, or just a limitation -- but unless my attempts to search for "zero" in the forums was just too broad, I couldn't find anything that mentioned it. Do you think it should be submitted as a bug, or as a documentation update request? (I'm thinking the latter is simpler.) EDIT: Actually, it seems that the ProFields Combo doesn't support the x=y|z format, only x=y. That'd be a different forum though so since it's related I will followup there. For now I'll have to adjust my IDs to start from 1, and make sure to remember this when using it as output.

The default IDs created for a Select Fieldtype seem to start from the numerical digit of 1. However, we're supposed to be able to define our own custom id and title values. In my case, I was trying to assign a value of zero as the ID assigned to the first title so that sort order could be properly maintained (floors of a building, where "ground" = 0). From my tests, with the standard Select Fieldtype, the ID is redefined automatically as the largest numerical value (ex: 0:ground, 1:floor 1, 2:floor 2, 3:floor 3 - ID for "ground" becomes 4). For the Combo field's internal value of a Select, its ID value ends up becoming null. I couldn't find if this is a documented and known limitation anywhere and am wondering if I'm just doing something silly. Trying to force the ID back to 0 will prompt the user to delete the associated entry. After trying to update the ID for "ground" to a numeric value of zero:

If you want to be sure to support Firefox, it's still best to develop in Firefox. Once finished, you then just need to visually inspect (under various viewport resolutions) with other browsers. Chromium supports more CSS and other technologies before other browser rendering engines, so if you develop to Chrome and then go back to Firefox to fix something, it's very often a forced regression type of fix, which isn't fun. Even worse is Safari... Very happy to see that you had the forethought to include (or in this case, exclude) printable formatting! The attention to detail is great. Congratulations on your launch!

I worked for quite some time coming up with this mock-up interface which originated from an architectural PDF of our building's floor plan. It's a (partially convoluted) interactive SVG, taking advantage of CSS and JS, along with a form control to highlight areas on the map, swap out active floor(s), and provide textual directions on how to find the particular location within our building (there's no good studies on accessibility for maps, so it's my best attempt at an accessible alternative/supplement for the SVG image). Example page in question. I'd like to, if possible, get the location name and description (directions) to be powered internally by ProcessWire. Each item also has required attributes: Level (floor) Attribute type: Collection, Service, Collection, Location An identifier that matches the SVG's hardcoded object path. (Ex: identifier is "space.glasby" points to #sspl-floorplan .space.glasby .item -- in this scenario, "space" could also refer to its attribute type) The biggest problem is that the SVG is not created dynamically, it is manually created/maintained from an Illustrator file, exported as SVG, and then customized with classes and IDs. So, currently, ProcessWire would need to be able to examine the structure of the SVG to identify items (and at a minimum, its floor and attribute type). I've been trying to think of a way to allow for integration for a couple weeks now, but I'm a little stumped. While creating the mock-up I was not considering that the data would need to come from somewhere and unfortunately(?) took complete advantage of static content. Now I'm not sure how I'd re-integrate things. All of the text that is displayed directly on the map is part of the SVG itself, so if it's to be powered by ProcessWire, I'm not sure if replacing it with JavaScript, re-processing it on save, or converting it to a PHP file (to allow dynamic string interpolation from a data source) would be the best solution here...or if I should admit defeat and leave it all as static content. I now have an idea of how to proceed, but I'd love to hear how you might've solved this, either from the beginning, or from my current sticking point above. I'm going to use a separate PHP (template for the SVG) file that will generate all of the various shapes except for objects/structures that will not change, and insert them dynamically into the SVG, and then overwrite the static SVG with what is generated; this will allow me complete control over the markup. This will get run on save of the ProcessWire page file. Unfortunately this means that I'll have to store the SVG path string in the associated field in ProcessWire as well. I suppose that's one (giant) step away from integrating an SVG drawing tool.

I feel bad bumping this topic, but I think some people might've missed, or misunderstood the importance of the reasoning for looking towards moving away from CKE4. The codebase of CKE version 4 will essentially be abandoned as of sometime in 2023 by the organization that maintains it. Considering the large amount of security issues that are consistently discovered in heavily used input/output handling JavaScript packages (whether due to custom add-ons or its core), and the fact that Ryan strives for a very secure system... The need to provide an alternative WYSIWYG module is evident. CKE5 seems like the least intrusive option (for users/clients). It appears as though he hopes to make it fairly seamless for site administrators and developers, but the integration changes aren't a 1:1 swap, so he'll have quite a bit to consider. It's likely that you'd still be able to use CKE4 as a module, just like you could continue using TinyMCE when it was removed from core -- as a separately installable module. If you wish to use standard textarea fields or Markdown-powered fields, there are add-ons for those too (already). You will still have choice, and that's one of the excellent things about ProcessWire. The only issue here is that Ryan wants to make sure that you and your clients have a stable, secure, and usable system. As always, you will still have control over your own system(s). ♥

I don't suppose there's any chance of getting these juicy forum board solutions added to related module documentation as Examples, could we? These are great starting points to common scenarios! The downside would be maintaining them for compatibility, but perhaps explicit notices with dates that the examples were created? So often I end up searching the website for answers to questions, but they're all over the place - the blog, documentation, api, forum (and not always the module forum). ? Just a thought. That said, loving these examples you're providing from actual client work you're doing. Thanks, Ryan!

Ah, that's more than I knew. In that case this is good for me to know about too! Thanks for that, and for your module solution!

A very nice and clean solution! Should your needs grow from this, you might enjoy one of the following options as well: Field Descriptions Extended Process Documentation

Although you can no longer signup for a new account to use the embedded Google Translate widget, you can still take advantage of it. I'll provide my solution should it be useful to anyone else. Having multiple options, depending on need, can be useful. <div id="google_translate_element"></div> <!-- Google Translate --> <script type="text/javascript"> function googleTranslateElementInit() { new google.translate.TranslateElement({pageLanguage: 'en'}, 'google_translate_element'); } </script> <script type="text/javascript" src="//translate.google.com/translate_a/element.js?cb=googleTranslateElementInit"></script> I've used this CSS to style it from its default, while still providing the (likely) required credit to its tool. #google_translate_element .skiptranslate { visibility:collapse; text-align:center; position:absolute; width:100%; width:calc(100% - 4rem); top:0; } #google_translate_element .skiptranslate * { margin:0 auto; display:block; } #google_translate_element .skiptranslate [id*=targetLanguage] { visibility: visible; } #google_translate_element .skiptranslate [id*=targetLanguage] select { border:1px solid rgba(0,0,0,.2); background-color:#F4F6F7; color:rgba(0,0,0,.7); } #google_translate_element .skiptranslate [id*=targetLanguage] select option { background-color:transparent; } #google_translate_element [id*=targetLanguage]::after { content:'Powered by Google Translate'; display:block; text-align:center; line-height:1; color:rgba(0,0,0,.6); } @media(max-width:575px){ #google_translate_element .skiptranslate { width:calc(100% - 2rem); } }

In the InputfieldEvents.module file's ___processInput method, there's an Exception exclaiming, "This inputfield requires that you set valid 'page' and 'field' properties to it." In what instances do inputfields (or any type of module) require page and field properties? I notice that many do not require this, but am not sure of the circumstances when they are required. So far I've just been copying/pasting from similar modules without truly understanding why.

Nevermind! ?

Going through this topic, I am hopeful the Intellisense after setting up VSCode will help me discover more in the core that's difficult to learn from external documentation. As much as I loved Atom and its graphical project viewer extension, the IDE capabilities are unfortunately problematic in my experiences. So here I am, giving VSCode another shot. Oh yes, since going through this topic, some have added extensions to their projects that VSCode has since added to the core editor, so some of you might be able to reduce the count of some of your extensions. Thanks to everyone for providing their findings (and snippets) so far! Color-coded bracket matching: Now in a core setting called Editor > Bracket Pair Colorization Renaming of matching HTML tags is part of the core via the rename ability (place cursor in/on tag name, press F2), though it currently doesn't work in PHP files (work in progress, I guess?) - alternatively, for simple matching replacements, you can double-click on the element name and press CTRL+D (or CMD+D on Mac) for automatic multi-select, then type the new tag name. These all have issues, so tag-rename or auto-rename-tag might still be preferred. Reformatting/Beautifying: SHIFT+ALT+F will automatically reformat the code of the file in focus, or currently highlighted code; also available from the right-click context menu (not yet sure how to define different formatting rules). URLs typed in the editor will be openable by default via CTRL+Click via Editor > Links. Not sure if people know, but it also offers code folding: CTRL+SHIFT+[ to fold/collapse, CTRL+SHIFT+] to unfold/open...or just use the caret symbols next to the text editor's line numbers. I think everything else (questioned raised) has been covered, or not yet able to be solved.

Thanks for the feedback, Rick! In this case, I'm planning on allowing tags on every page that contains content. Although education-related, we're a public library, so we don't actually teach per-se, but the actual content has no limit. I hadn't yet attempted implementation yet so I wasn't aware ProcessWire doesn't allow multi-word tags, but that could potentially be solved with hyphenation. I'm mostly wondering what people have come up with in terms of rules or procedures on best-case scenarios for instructing users on how to take advantage of tags. I do realize, however, that this may be dependent upon implementation, though I'm curious of first-hand scenarios of others, to maybe apply to my own. (You kind of touched on an idea with the course category subset.) ? Thank you!

So, just like naming variables, trying to come up with how to properly create tags that would be understandable, usable, and not "one unique tag per every item", how do you all go about creating your tagging system(s)? Do you give access to creating tags for your customers? If so, have you come up with instructions or ways to help them satisfy their desires without overloading the website visitors with unusable overabundance of named tags? I'm reviewing a secondary site for my current employer that I have not had control over, and with free reign, there are over 800 tags on about 200 pages (and many pages don't even have any tags assigned). Some tags are full sentences. I'll obviously need to describe what a tag is to my coworkers, but even I'm having a hard time coming up with proper ideas for tags, and how best to determine what would be good and what wouldn't. (We're a library and therefore deal in education, so topics can be extremely wide-ranging on any number of subject areas.)