teppo

Don't worry, that's not a bad sidestep ? I mean – sure, I've seen folks take a library or framework that perhaps even boasts about being "accessible" and implement something with it and actually think that they've now got it all handled. While that'd be nice, in reality we're far from that. Where I currently work we care a whole lot about accessibility. Part of that involves not believing everything third parties say, but actually validating the services we build, and making sure that they are up to standards. For an example I'm currently not aware of a carousel plugin that would properly fulfil WCAG level AA – let alone AAA – out of the box. While I'm kind a Slick fan myself, even their idea of a11y is rather cringeworthy: Yeah, because that's all there is to accessibility, right? Similarly one of the biggest issues I see with a lot of these modern web-apps (or whatever you choose to call them) is indeed exactly that gross neglect of "proper markup", and all that follows: "Can't we just use something generic and sprinkle it with some magic dust to make it accessible? Isn't that what ARIA and all that stuff is for anyway?" Sure, assistive technology has been evolving and these days it is indeed possible to tell the browser that a div is a button. Tricks like that might not work everywhere yet, but support is likely to increase. Regardless there are all sorts of problems with that approach, one of the biggest ones being is that we're essentially offloading accessibility and usability to someone else and expecting them to catch the ball where ever and when ever we decide to drop it. And then there's the problem that something as intangible as accessibility – or usability for that matter – is really hard to summarise into a set of algorithms. Each and every case is different. It's a lot like assessing code quality programmatically: sure, to a point it can be tremendously helpful, but the reality is still that (for the time being) we still need humans to complete the assessment. Tech alone is not the solution. I know there are some parallel topics going on here and this was perhaps related to another idea altogether, but: this is a very good point, in my opinion. "React made me do it", or "it's like this because components" are not very good excuses to mess things up. It's just tech, and particularly unopinionated tech for that matter. The problem isn't React or components – it's how people use them ? I feel that this is again very much related to the stuff Brad Frost wrote about in frontend design, react, and the bridge over the great divide. To summarise, even though these days "frontend" goes way beyond HTML+CSS(+JS) and simple GUI level tasks/responsibilities, there's still plenty of demand for so-called frontend designers. Folks who are specialists in crafting that clean, semantic, usable, accessible, and (in the long term) likely maintainable "front of the frontend" layer. That's roughly the direction I've been going on for a while now. With a few twists. We discussed Tailwind with Antti a while ago, but I've yet to try it on a real project. Some of the examples I've seen look kind of horrifying, but admittedly I've recently found myself gravitating towards the general idea of utility classes. Perhaps it's the sort of sites I work on, but one key problem for me is that I often find myself using same components (there's that word again) over and over again. So far I've found this easiest to handle by using as little markup as possible, and delegating the bulk of the visual side to CSS, utilising a loose adaptation of the BEM methodology to manage these so-called components. Grid is a big reason I've used frontend frameworks, so once that's properly usable (read: no one demands IE11 support) those are going to feel less and less attractive. I used Foundation for the longest time, but their built-in components are – excuse my language – kind of crap. Menu is completely unusable, and other components have at the very least various a11y problems. I haven't yet given a good try to Uikit. Probably should, but after investing all that time into Foundation I'm somewhat vary about diving head first into another "full-featured" framework ?

That is so true! Our industry has a long tradition of adopting both tech and practices because they worked for [insert a name of a web giant here], with little understanding of how and why they worked – and even less consideration given to the question "is this really a good idea for us?" ?

Interestingly one of the first things to consider when making a site accessible – according to experts, whom I have plenty of trust in – is to always use the correct semantic elements. Screen readers, for an example, have varying support for aria properties and roles etc, so overall I have very hard time believing that Twitter did this because it's somehow "the best way to handle it". Rather it looks like they didn't think of accessibility until the very last moment, and since it was essentially added as an afterthought, modifying the source (read: existing components) big time was no longer feasible. Another thing that points to that direction are complaints I've seen from regular users about the UX of the new service. It's not just about the missing labels and odd ("non-standard") icon choices, but overall the whole experience doesn't seem particularly well thought out. Some of that is no doubt a result of trying to control the user experience as much as possible (prioritised content and all that), but the new site does feel a bit overengineered and underdesigned. Also, I'm not really sure how nesting dozens of non-semantic elements to create what could be done with a couple of semantic elements and a few of lines of CSS – and then sprinkling it with loads of extra attributes and JavaScript magic to simulate what those semantic elements would've done right out of the box – is good for performance. Or long-term maintainability for that matter. ... I'm sure you're right in that the way these services are built is intended to minimise the amount of time it takes to get new developers on-board, or because the internal processes demand it, or because it's difficult to find those devs with crazy ninja skills who can single-handedly master every single aspect of a modern web application without even breaking a sweat. Still, to me this seems like a larger, almost industry-wide trend – one that Mike Taylor quite aptly described as the backendification of frontend development. Anyhow — the point I'm trying to make here is that while there's no doubt that products like React make all sorts of interesting stuff possible (and feasible), that still won't magically make it a good idea to neglect even the most basic design / architectural principles of the "front of the frontend" (as Brad Frost has described his area of expertise on various occasions). In other words: I'm not saying that everything new must suck, just that it seems like too many devs are currently diving head-first into a world of hurt chasing something new and shiny ?

Not sure if this a topic for the dev talk area or perhaps rather the pub, but just wanted to share this little gem. It's a small part of the new Twitter web site/app. I'm not quite sure what's going on with that site – but whatever it is, it's getting out hand, and that might have something to do with current craze with components within components within components within... you know the drill ? For the record, I was trying to figure out what that weird star-icon in the top right corner is/does. Turns out it's some kind of "top tweets on" button (whatever that means), but to learn that you'd first have to a) just randomly click it and see what happens, or b) dig through a whole lot of messy markup to get to the aria-label. Another thing I found interesting is that when you hover the icon, it gets a background colour. Now, there's nothing particularly interesting in that alone – we have the :hover and :focus states in CSS exactly for that purpose – but the thing is that when you hover over the icon, JS adds the blatantly obvious "r-zv2cs0" class to one of it's parents, which in turn results in that slight shade of blue you see on the site. I'm glad they've made the effort to make that mess of a markup accessible by applying aria properties and all, but is this really the direction we want the web to go? The obvious ugliness of the markup is one thing, but when you have to explain to the browser things like "this particular div here, buried ~20 levels deep in other divs, is actually a button you can focus on"... that feels wrong on so many levels ? (And sorry for the clickbait title, by the way.)

Awesome, thanks Mike! ?

Thanks @Mike Rockett, looks great so far – will test properly later ? The editor has indeed been having some issues lately. Pete has been digging into this, and we're keeping an eye out in case an update is released that would take care of this.

That's great news right there. Not sure how things have progressed since then, but the last I checked it seemed there were a lot of perceived problems with version 5, and the answer was always "this will be really difficult because we use this new data model". I'm sure that 5 will become a great editor, but whether it will become a great editor for HTML still remains to be seen ? I'm tempted to draw lines from the CKE5 to another work-in-progress content editor that has been in the headlines lately: Gutenberg. In both cases it appears that the team is pushing an idea they wholeheartedly believe in, while a notable percentage of their existing users are telling them that it's a massive mistake. Interesting times ?

That changes things quite a bit. Personally I've never been a part of this kind of team – as strange as it may sound, I've worked in teams where there are backend developers and so-called full-stack developers, but never a "pure" front-end developer ? You've definitely given me something to think about here! Features that are not tied to a specific template have in my use cases usually been partials with very little "logic" behind them, but this would actually be a nice use case for shared (sub)controllers as well, which is something I'll likely dive into soon. Basically the idea is to have a controller that isn't tied to a single template, but rather can be used by multiple templates. Also controllers that inherit other controllers – "base controllers", or whatever they might be called – is another way to achieve shared features. Overall there's a lot you can do with current codebase, but since there are different use cases, it's very much about finding a balance between "not opinionated enough" and "too opinionated" ? As for layouts, I've found the concept really useful, and since I use them in pretty much all projects I work on, this is something I wanted to have built-in and ready-to-use within Wireframe. Placeholders are a key part of this, as they provide an easy way to embed views (of which there may be one or more for each specific template) within commonly shared layouts –aAnd because layouts serve a different purpose from view files (individual views for templates) and partials (smaller pieces of content intended to be embedded within layouts or view files), I've opted to store them separately. This is again one of those cases where it's all about finding the right balance and figuring out what should be available out of the box and what to leave for individual developers to figure out on their own, and I feel that current split between layouts/views/partials is a reasonable one – but because I know there are different opinions, much of this is actually already configurable. Also, since layouts are optional, one can always opt out from using them ?

@Lance O., are you using Markup Sitemap XML, which is the earlier module from Pete, or Markup Sitemap, which is a newer one developed by Mike Rockett? As Dragan said above, you should always post module-specific questions to the existing support thread for that module. Let us know which module you're talking about, and I can merge this thread to the correct module-specific support thread. Thanks!

Sounds familiar ? SAML is actually a pretty simple concept. I'm not an expert, but to summarise: LDAP is a general purpose protocol for communicating with directory services. When it comes to authentication, typically the way you'd set this up is by providing a local login form (ProcessWire's native one or something else), and when the user has provided credentials, you use the LDAP protocol to pass them to the AD server for validation, and then – depending on the reply – either log the user in (creating user object in the process if necessary), or display an error if provided credentials couldn't be validated. SAML is a SSO standard for authentication. Here the identity provider (often ADFS or Azure AD) takes on more responsibilities: in the case of SAML Auth 1) the user attempts to access the admin or other protected area, 2) the module detects this and redirects the user to the IDP's web based GUI, where 3) (unless there's already an open session) the user has to provide authentication details, after which 4) IDP redirects the user back to the site with a SAML response, and finally 5) the module either logs the user in (creating user object if one didn't exist yet) or displays an error. The reasons I personally prefer SAML is that it's an SSO solution – which means that if the user is already authenticated to the AD server they don't have to authenticate again – and that the IDP actually handles a bigger part of the process, meaning that you don't have to pass credentials to third party services, etc. That being said it doesn't really matter that much which approach you use. If the client has a backend capable of using SAML, I'd recommend that, but if not then LDAP is a decent fallback. To be honest I'm not really familiar with the service layer, but most commonly you'll find some Microsoft product from the other end. If there's ADFS (Active Directory Federation Services), it should support SAML. On the other hand if the client is using Azure AD, there's actually no LDAP support at all (unless they also use Azure AD DS), so in this case SAML might be your only option.

Just checking: where / at what point of the installation process is this error coming up, and what does it say exactly? I'm currently testing this on a 3.x site and so far it seems to work. Note that if you're installing the module from the Modules section in the Admin, it will complain that the module hasn't been marked as compatible with 3.x. This alone doesn't mean that it won't work with 3.x, though it is good to be worried when you see a message like that ?

I get your point, and agree – to a point. When I first came across the idea of render functions (with that specific name it was some bit of code from Ryan I believe), this was exactly what I thought ? Since then I've used render-functions in numerous projects, and while in some cases it still feels a bit "dirty", in real world it can be a tremendously helpful strategy and hasn't really caused me any notable headaches so far – quite the opposite. These days I don't have a major issue with code that generates markup as long as it's clearly separated into its own container, i.e. "siloed" properly. While I don't encourage mixing business logic with presentation, this is one of those cases where the line is a bit blurry. Also, as a minor note I don't think that we should separate logic and presentation based on the language alone. PHP can be used to create "presentational" content, so overall it's more about what you do than how you do it. Something like Twig is supposed to be "purely presentational", but you wouldn't believe the complexity of some of the logic I've seen implemented in/with it. (But this is a topic for another discussion – templating languages vs. using PHP as a templating language, and so on and so forth.) Awesome! As far as I can tell this is actually really close to this rough idea I mentioned earlier – or, more precisely, it would be one possible use case for (or variation of) it: > Another idea I've been toying with would be subcontrollers (or child controllers, or partial controllers, or whatever terminology makes most sense) I'm not entirely sure if it actually needs to be a separate concept ("chunks", or whatever that would be called), but that's not necessarily a bad idea, if it makes the concept easier to grasp. Technically it should already be possible to instantiate a new Controller, provide it with a View file, and then render the output within, say, another Controller. That's what Wireframe itself does for the page, though it all happens automatically. Another thing that might not be obvious yet (I'll have to check the docs relating to this) is that there are two use cases for views: They provide alternative ways to render a Page. For an example the default view might render markup (HTML) for the entire page, and another might render an RSS feed for a list of news items. They can be used to populate View Placeholders: if you request <?= $placeholders->aside ?> in a layout file used for the "home" template and add a view file at views/home/aside.php, Wireframe will automatically populate the "aside" placeholder with the content of current page rendered with that view file. Anyway, I'll definitely dig into this topic a bit more and come back with some sort of solution, hopefully – thanks for linking to the TemplateEngineFactory example ? Thanks – this list was quite helpful. For the record, here's how I've handled these examples in my past projects: For menus I've used MarkupSimpleNavigation, and later MarkupMenu. In the boilerplate profile I do have partials for these, but they just call the render function of a markup module. Breadcrumbs is in my case usually a simple list of parents, thus I've used a "dumb" partial file with a foreach loop. Here's an example. Sidebar, again, tends to be either a single RTE field (something like sidebar, aside, or perhaps right_column or left_column), or sometimes a predefined list of multiple fields. Again a valid use case for so-called dumb partial files, but this is actually exactly the use case for which I originally added the ability to use View files as View Placeholders. Repeating elements covers a wide area of different content, but in my projects these have usually meant one of two things: A news list or something similar, with predefined header, list of items, and often some sort of "footer" area as well. These use cases I've usually solved with render functions. Repeater, RepeaterMatrix, or some other repeatable fieldtype. "Dumb" partials with some foreach rules, or native field rendering (particularly useful for RepeaterMatrix). Note that I'm not saying that your use cases are invalid, or that the list above would be the "correct" way to handle these. It's just that I can see why this hasn't been a notable issue for me – but this also helps me understand the kind of use cases you've run into, and thus figure out how to continue from here on ?

Great to hear that it works now. The problem with automating this is that I don't want to assume which templates should become searchable. That being said, I could add an install-time setting to pick templates to add this field to, or alternatively a module config setting that fetches this info real-time from templates. I think that'd be a pretty nice solution overall, so I've added that to my to-do list. There was – it just wasn't working quite as expected ? I hadn't tested this properly: translatable strings were defined and cached too early during the module's bootup sequence, with the result that the language of the user wasn't actually set yet, and thus you always ended up with the default (english) versions. This should be fixed in the latest release, 0.6.2. There's a basic demo here with most public-facing search-related terms translated: https://wireframe-framework.com/haku/. Sorry for the inconvenience, and thanks for digging out these issues!

Yeah, or do that (after updating the version in the module file) if you're in a hurry ?

In your .module file you've specified version 100 (1.0.0), so that probably overrides the value at modules.processwire.com. You should update your module file (in GitHub) instead, and the modules directory entry will auto-update after a while.

I'd first look into setting up SAML integration. Overall I think that a SAML powered SSO solution is always easier and more user-friendly approach. SAML Auth handles this quite nicely, though it may take a bit of configuring to get everything right, and it also looks like the module hasn't been updated in a couple of years – so I'd first make sure that there are no issues with the bundled OneLogin's SAML PHP Toolkit. ... and if there are, perhaps you could try updating it and submitting a pull request? ? There are some LDAP modules as well, and I actually have one just sitting on my local machine that I'd really like to share. It's a module I built in my last job for a client project, and I know it's powering at least one production site already, but I just haven't had the time to add the last finishing touches on it yet. Also, I don't really have a need for LDAP stuff in my personal projects, so there's that ? Anyway, I can't give a specific timeframe but I'll make a note to get the module finished and published.

Hey @VeiJari, thanks for your report ? Those warnings were fixed in version 0.5.1 – I keep forgetting that core classes don't use strong typing for non-object parameter values. Lesson learned: always develop with debug mode on (or use something else to display all warnings). "Indexed 0 pages in 0 seconds" isn't related to the warnings. This just means that the module couldn't find pages with your configured search index field. I've added a warning message for this situation, explaining what happened and what to check first (that your index field is actually added to at least one template with existing pages), but other than that I'd have to know a bit more about your specific setup to answer why this is happening. Additionally (with latest release 0.6.0) I've changed the defaults so that any non-trashed page with the index field is now automatically included. Previously the default selector for this feature only included public pages, which meant that hidden and/or unpublished pages were not indexed (via the "Index pages now?" feature, that is – saving the page itself indexed it as expected). -- If you're still getting a message that indexable pages couldn't be found, please let me know how you've configured the module, and which version of ProcessWire you're using. Also please make sure that you actually have indexable pages to begin with – unless you've specified a selector string for the "Index pages now?" feature, this is the selector that finds those pages for you ?

If you're interested in ironing this quirk out as well, here's one possible solution: https://www.media-division.com/correct-name-capitalization-in-php/ ?

Glad to hear that the error has disappeared ? The problem might've had something to do with your environment, but the resulting error is an interesting one. In this case something attempted to change current working directory into one that wasn't allowed, so PHP threw an exception – and since throwing exceptions from __toString() is not allowed, that resulted in fatal error instead. This seems like an unexpected result, so it might be worth investigating if it can be avoided, though I'm not sure if there's any sensible way around this. As long as __toString() does anything even remotely complicated, there's a risk of running into this issue.

Thanks for sharing this, EyeDentify – nice and simple ? Just a little note before folks go implementing IP logging: IP addresses are considered personal data, and as such you should keep GDPR (and similar legislations) in mind. Here's SE question that covers the details related to logging IP addresses: https://law.stackexchange.com/questions/28603/how-to-satisfy-gdprs-consent-requirement-for-ip-logging. (The general consensus seems to be that you don't need to ask for permission before logging IP addresses, but there are other requirements you do need to keep in mind.)

Hey Bernhard! Just a heads-up that I've moved this older RockMarkup thread to the Module/Plugin Development area. Please let me know if you'd rather prefer to have it merged with the module thread – though if we merge it, posts here will probably show up before the initial post in that thread, so it may look a bit weird ?

You may need to be a bit more specific than that: what exactly do you mean when you say that the URL doesn't work? Is the screenshot from your actual site, and if so, could you add a link to that? Or is this an example that you're trying to achieve? Note that I've merged your question to the Markup Simple Navigation support thread. When you have a question related to a specific module, post it to the existing support thread for that module – thanks!

This is included with the default .htaccess file, but disabled by default. See section "4. Protect from XSS with Apache headers". It seems to me that this should probably be enabled by default, but I'm guessing that it was left disabled for a reason – @ryan would be the best person to say if those reasons still apply.

Make sure that the translated versions have the %d placeholder as well – from your description it seems likely that they don't.

Absolutely agree with this – use case for the data matters a lot! In my experience MySQL queries (with decent indexes) tend to be pretty fast until you reach the scale of millions of rows, but if this is going to be a public-facing service that gets a lot of hits and needs to generate all sorts of reports real-time then definitely consider alternatives right from the get-go. Might be a good idea to look into them anyway, but if it's a one-off project and you're likely to stay in 200-300k record range, you're probably not going to get a major benefit out of them. That being said, if you already know what your data is going to look like, you can take some guesswork out of the equation by starting from a simple proof of concept: create a database table for your data, add a script that generates some 200-300k rows of random mock data based on your actual expected data format, and build a proof of concept graph to display said data. If the database concept doesn't pan out, i.e. it's too slow or something like that, you can just swap that to something more performant while keeping other parts of the application. Either way it's often a good idea to build your product in layers, so that if a specific layer – graph library, database, or something in-between – needs to be swapped for something else, other layers remain more or less the same ?