teppo

One more: I'm also seeing this error for the 'user_agent' column.

Hi @Mike Rockett – I'm back with the endless requests ? How do you feel about supporting WireCache in MarkupSitemap, possibly as an alternative to (if not instead) MarkupCache? The thing is that due to hosting-related reasons caching in the database would be easier for me, while current MarkupCache implementation is slightly problematic. I could send you a PR (or merge request, as you're using GitLab) in case you're interested.

One idea would be visiting the Packagist GUI and using the "update" feature from there, and apparently there have been cases where simply logging in can help. I'd also make sure that the webhooks are still in place and functioning properly (I guess this depends on how you've set things up between Packagist and GitHub) ?

These sound like a good addition to rule 5B. Blocking access to known sensitive files is exactly the point of that rule ?

A quick note on this one: while at first it sounded a bit over the top, I'm kind of warming up to the idea. Sure, there are problems and may not work in all situations, but it might make sense as an optional setting in the .htaccess file. There are already a number of optional sections in there, ones you can enable manually if they make sense in your context. This could be one of those: instead of blacklisting specific files, you could choose to disallow everything except for those you know your site to require. Just saying.

Hey Ryan! Great stuff again ? I wasn't quite sure where to post this, so asking here first: we're using Composer to set up ProcessWire, but for some reason the dev branch hasn't been updating for a while – any idea what's going on? If you take a look at https://packagist.org/packages/processwire/processwire#dev-dev you can see that the latest timestamp is 2019-08-16 18:11 UTC.

Just a quick note from moderator: this thread is not about module development, so I'm moving it to the "General Support" area of the forum. Thanks.

Note from moderator: since this is not a support thread for a module, I'm moving it to the "Themes and Profiles" area of the forum instead. Thanks!

I wrote a longer reply to the issue mentioned above, but long story short: yes. Currently the contents of these files can be (and by default will be) world-readable, which – depending on the use case, i.e. the code stored in the files – can be considered anything from "probably unexpected but mostly harmless" to "a major issue". As a quick fix you can include a .htaccess file in your module directory preventing access to files with .ready or .hooks extensions, but in the longer term I would definitely recommend refactoring the module to use standard .php extensions instead ?

Thanks for the update! No worries, take your time – my current use case isn't particularly time-sensitive. I'm just happy to know what the long(er) term plan with the module is ?

@nbcommunication @Macrura Sorry to bother, but could someone clarify what's the current state of this module? This thread contains posts about two separate versions, which are apparently not compatible – if the official version is still the one from Macrura, I think we should split posts about the "other version" to another thread if possible. Note that if that is to be done, it should really be released as a new module. .. unless the plan is to make that the official version? I'm currently starting a new project with this module, and had a bit of trouble figuring out which version to install ? That's a good point! To me it sounds like implementing a "Mailer picker" for each module separately would result in awful lot of duplicate work/code, though perhaps it would indeed be a reasonable feature for at least some of them (such as FormBuilder). I have never been in this situation, i.e. I've always used one mailing method per site, so not sure what would be the best approach. One option would be providing a hookable method for sending the message, in which case this part could be overridden if deemed necessary ?

SearchEngine 0.10.0 was just released. Not a whole lot of stuff in this release – basically just one new feature, one minor addition to the default theme CSS, and some PHPDoc improvements. ### Added - New Renderer::___renderResultsJSON() method for rendering search results as a JSON string. - Additional CSS rules to make sure that visited links appear correctly in the default output. While building an AJAX suggest search feature it occurred to me that it would be nice if SearchEngine could return search results as JSON out of the box. Newly added renderResultsJSON() method provides this capability, and new settings results_json_fields and results_json_options allow customising what gets returned, and how. More details (and an example of using this feature) in the README: https://github.com/teppokoivula/SearchEngine#json-output.

Moderator note: this thread was moved from "Modules" to "General Support", as it's a question about a core module.

I don't want to dismiss this issue, but I also think that people sometimes overthink the whole field naming thing a bit. When you're creating a new field ... Decide if this field is something you can reuse elsewhere. Things like "images" or "summary" are obvious candidates, and then there are the likes of "color", "width", and "background_color" that are likely to fit into this category as well. If you can see further use for the field (or rather the data it represents), go with a generic name. If the field is very specific to the use case (based on it's purpose, context, or settings / formatting rules etc.) don't try to get too creative with the "always reuse" idea. If it's a field that's specifically designed to hold google_analytics_id, just name it accordingly. Reusing fields is the best practice, but reusing fields for something they're not meant to do (and/or where they'll make no sense at all) will just mess up your information architecture – not to mention the issues it'll cause once you realise that in a particular use case you actually need to tweak some field setting that cannot be changed in template context. (Note: I'm aware that you can nowadays make a lot of stuff changeable in template context. In my experience it doesn't necessarily mean that they work as expected, and even then it can result in a whole new layer of complexity. Personally I try to avoid that.) 50+ fields is plenty, but especially if it's a moderately big project, in my opinion it's nothing to be worried about. ... oh, and one more thing: sometimes I see folks create loads of "duplicate" fields such as email_1, email_2, email_3, etc. That's one one easy place to optimise: use one of the repeatable fiield types, ProFields table, etc. Table is particularly great because it can handle large amounts of data in an efficient manner ?

Good morning! AdminBar 2.3.0 was just released. Here's the changelog for this version: ## [2.3.0] - 2019-08-29 ### Added - Gravatar image support for the "user" item in Admin Bar. - Support for sorting Admin Bar items manually with the AsmSelect field in module config. - A changelog file. ### Changed - Protect logout link from accidental clicks (script or otherwise) by converting simple link to a logout form. - When modal window is opened, hide children and view tabs with CSS first in order to prevent flashing content. Due to the manual sorting feature mentioned above there was a change in the data structure, so note that if you're already running AdminBar and have modified the visible items in the bar, you'll need to reconfigure those. This was the easiest way I could figure out to achieve free sorting feature: Minor note: currently it's possible to add the same item to both left and right columns. I didn't see a reason to specifically prevent this, so it's kind of a feature – though not sure if that's something you should ever do from a UI/UX perspective ?

Looks like this library is added as a Git submodule. The GitHub zip download won't include submodules, so it's a bit of a nuisance. You'll likely need to add them manually, or do a git clone + git submodule init + git submodule update (or something along those lines). Might make more sense to bundle the code directly into the repository, though that's obviously up to @Adam. Either that, or just include instructions on getting those files via Git – though it's probably worth noting that with the submodule approach the module won't be directly installable via ProcessWire Admin (which may or may not be a problem) ?

This is most likely because the module is still waiting for approval ?

Hey @VeiJari, This should be doable by either hooking into the Renderer::renderResults() method and replacing it with custom method of your own (that doesn't contain the path), or simply by setting the result_path template string to an empty string or null via config options: $config->SearchEngine = [ 'render_args' => [ 'templates' => [ 'result_path' => '', ], ], ]; Let me know if this doesn't work, though ?

Just for the record: SPF records are specific to domains, so that's not something you'll find in the messages specifically. If you're using a domain that has SPF record in place, your best bet would be making sure that wherever Gmail is sending the messages is included in that record – though if those "manual" messages you mentioned were sent with same host/domain and also via Gmail, that's probably not the issue. When you say that there are differences in the headers, I'm wondering if you're sending manual messages directly via the Gmail UI, and automated messages via code, or something along those lines? Definitely make sure that you're using correct (and identical) domains etc. For a better idea about what might be going wrong, be sure to give one of those testing services (such as https://www.mail-tester.com/) a try, i.e. send an identical message to them and see if they flag any issues. And finally, keep in mind that automated messages often look suspicious based on their content alone – short text with various flaggable keywords and a link (or worse yet, multiple links). I've had plenty of trouble in the past getting such messages through reliably, particularly if the receiver has strict anti-spam filters in place. Assuming that those messages are customisable, you might want to try rewrite them to look more "natural" ?

Tailwind is utility-first framework. The key difference between something like Uikit and Tailwind is that latter has none of the typical CSS framework components built-in. For an example, here's an example from the docs for creating a "button component": <button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded"> Button </button> Colors and sizes (such as the "2" in "py-2" etc.) are configurable, so you can have as many or as few of them as you want, and the names can pretty much be whatever you want them to be (py-thon). Either way you're always building your UI using really simple (the word "atomic" comes to mind) rules. While Uikit has some similar utility classes (and so does Bootstrap), Tailwind has a massive number of them, even without counting the pseudo states (bg-blue hover:bg-blue-dark), responsive classes (p-6 md:p-8 lg:p-10), etc. You can still create your own "custom" components, so that when you add some class – such as "btn" – to an element, you actually get the same thing you would with the rules in the example above. Typically this is done by defining the class in SCSS: .btn { @apply font-bold py-2 px-4 rounded bg-blue-500 text-white; } .btn:hover { @apply bg-blue-700; } Technically that this is something you should only do if you really have to repeat the same string of classes multiple times, though ? Personally one thing I've always struggled with "traditional" CSS frameworks are the components they come with. While they often look quite nice, I've almost never had the chance to actually use them as-is (either there's a predefined PSD layout or something like that, or the client demands changes, or the component is just plain bad) and thus I've basically ended up designing my own component library on top of the one provided by the framework. In most of my projects I've only used a framework like Foundation for the grid implementation. That's where Tailwind comes in: you can build exactly the components you need, BUT you still get certain benefits of a framework, such as globally defined fonts, colours, spacings, etc. I've struggled with this a bit, and I have to agree that to me personally the utility class approach often looks really ugly, and the shortcut class names etc. are hard to decipher. I'm not yet at the point where I can just glance over an element and instantly see what it is or how it's styled. That being said, I don't really think that this is a major issue for most projects: the size of your HTML is unlikely to become a real bottleneck. ... and if it does, you can always use the extracting components approach mentioned above. Use Tailwind for prototyping, and then convert the combinations you use often to custom components (or custom utility classes) ?

Please do – the core would definitely benefit from this ?

Just to add to this a bit: I've found it a bit problematic if you're, for an example, working with nested structures where the nesting level should affect things. That's one example where, to my best knowledge so far, it's usually easier to rely on custom classes. You can still make use of @apply and similar features behind the scenes to make use of Tailwind's features as much as possible, but the point is that you can't always rely on directly applied Tailwind classes alone – at least not without creating solutions that are either inflexible, or unnecessarily complex ? As a disclaimer I'm currently building my first site with Tailwind. It's been a bit of an emotional rollercoaster: at times I find Tailwind utterly awesome, while the very next moment I can be really frustrated with it as I'm once again struggling to figure out what's the Tailwind version of some CSS rule I already have in mind. (For the record, https://nerdcave.com/tailwind-cheat-sheet has been a big help in this regard.) I've been constantly tweaking my approach, going back and forth with things like components and custom utility classes, trying to figure out how to best combine those with native Tailwind features, when to add a new "spacing" or color (or something similar) to Tailwind's config vs. just applying a one-off custom value instead, etc. That being said, I've already got a list of do's and don'ts for my next Tailwind project, so it should go a lot smoother. For the past year or so I've been deeply invested in a BEM type approach, and in some ways Tailwind is the opposite of that. That shift in mental models has definitely been holding me back a bit. After my next project with Tailwind I hope to have a more informed opinion, but currently if someone asked me if they should use Tailwind for their next project, I'd have to reply with "it's complicated" ?

Hey @tthom_pw! Looks like this isn't currently possible. I'm working on version 2.0 of the module, which will include quite a few changes in fact, and I'd be happy to implement this once that's ready to be released. Sadly I can't give you an exact timeframe – probably "sometime within next few months", but that's just about it. In the meantime you might find other modules more suitable for this purpose. For an example my ProcessChangelog creates a relatively easy-to-follow log of events – it doesn't integrate with VersionControl, so there's no way to link changelog with revision numbers etc. but if might be a more sensible way to get an idea of what changed and when. Hope this helps a bit.

You're correct that AdminBar only applies to users who are logged in. There's no "guest user" when it comes to AdminBar – only superusers and users with the "adminbar" permission will see anything out of the ordinary. Regardless, since AdminBar outputs features visible on the front-end, it's very much connected with everything else happening there. What you're missing here is that being logged in won't disable those browser extensions or nullify the effects of third party libraries – so it's not true that those features would only apply to users who aren't logged in. As such, it's very important that admin bar is as "tolerant" as possible, so that it won't break or cause new problems if you decide to implement a new JavaScript library on your site (or enable a browser feature/plugin).

You're right that browse isn't really a link – that's definitely one that shouldn't be represented by <a> tag ? Logout is a border case: technically it can be a link, just like it is right now, but you're right that it probably shouldn't be. On the other hand even changing it to a form isn't, in my opinion, quite enough – it should also provide and validate some sort of nonce/token, just to be sure that it can't be abused. There's no redirect after logout at the moment either, so that's not a major problem. Anyway, I'll figure something out for the next minor release of the module. Create is one of the cases where a link usually makes sense: it should be a link to the "new page" view in Admin in case the modal mode is disabled or JavaScript is for whatever reason out of equation. That being said, I've almost never used the "name format" option, so I didn't even think of that – that behaviour is indeed problematic and needs to be addressed somehow ? It just occurred to me that my earlier explanation was flawed ? If you reload, say, just the <main> element within your <body>, and Admin Bar remains as-is, the links/buttons there will point to the wrong page. As such using such plugins you probably would need to reload Admin Bar as well. I could add support for modifying target/parent IDs with JavaScript, but that would still require extra steps for the developer anyway. Also thought about using URL in this case, but that wouldn't help, as Admin Bar can't know for sure if you're using "real" URLs or some custom format (via URL segments, History API, or something else.) Currently I'm thinking that an option for reloading / re-rendering Admin Bar via JavaScript might actually be the best option here: in most situations the module would work right out-of-the-box, but if you do use some sort of front-end routing / transition code, you could somehow tell it to update. Not a perfect solution, so any suggestions are welcome. -- By the way, if – and only if – it turns out that one/some links can't be easily switched to buttons without sacrificing something else, do you know if role="button" would help at all? I wouldn't use that unless I really have to (reinventing <button> with ARIA attributes is almost always just plain dumb), but this might be one of those cases where it's actually the most sensible approach – it would be an improvement in terms of accessibility, but I've no idea if it would help with preload/prefetch/etc. features ?