teppo

I may have missed some of the points made here (sorry in advance), but regarding links opening in new tab/window: please keep in mind that this is a problem from accessibility point of view. For typical desktop users with decent eye sight etc. this is usually not a problem – and in fact it may be nice in some cases that a link automatically opens in a new tab – but for most screen readers (apps, that is – and thus their users as well) it's a real problem. From what I've heard/read, it can entirely mess up their understanding of the context. WCAG advises that if you're about to open a link in a new window, you should provide a clear signal that this is going to happen. This can, for an example, be a note at the end of the link text: "(opens in a new window)". If you care about accessibility, think twice before you use target="_blank". And for those cases where the client requests this, be sure to inform them that it will likely cause issues for some users. If the client still wants to go with it then by all means do it, but I've found this argument to resonate quite well with most sensible people ?

Hey folks! I've been a bit quiet here about Wireframe, but the thing is that I've finally got a couple of "real sites" (as in not my own projects) to implement it on, and that has brought up some new requirements and a few issues. I haven't had the time to dig into a whole lot of really new stuff (components and such), but I have made a lot of other updates to the framework. As such, Wireframe 0.6 was released late yesterday. (A release on Friday the 13th, consisting of a total of 13 commits – not being superstitious here.) I've been updating the docs at wireframe-framework.com as well, but some parts remain a bit outdated. A lot of what happened in this version doesn't really affect the use of Wireframe, but some things do – and one change may even break some existing implementations: It used to be possible to set the view file or layout from Controller with $this->view->layout = "some-layout" or $this->view->view = "json". This has been deprecated and removed in favour of a setter/getter API: $this->view->setLayout("some-layout") and $this->view->setView("json"), and getLayout() / getView() for reading the value. In addition to some obvious benefits from type hinting etc. this also makes it harder to accidentally change something when you thought you were just passing a variable to the View ? There are now three ways to perform actions and pass data from a Controller to the View: Controller::init() (triggered as soon as the Controller class is loaded), public methods (which are made accessible in the View as $this->method_name), and a new addition Controller::render() (called right before the page is rendered). In most cases where one might've used the init() method before, render() is a better choice, as there's less chance that code will get executed "unnecessarily". In addition to existing Page::layout() and Page::view() methods there are now specific setters/getters: Page::setLayout("layout-name"), Page::getLayout(), etc. Original "unified setter+getter" methods may actually get removed at some point, as they're often ambiguous and make code arguably less readable. Quite a few other changes as well, some of which improve performance and others that make the API more polished. Some bug fixes too, though those mostly apply to what I'd consider "border cases" ? Here's the full changelog for Wireframe 0.6.0: ### Added - New Page methods Page::getLayout(), Page::setLayout(), Page::getView(), and Page::setView(). - New Controller::render() method, executed right before a page is actually rendered. - New ViewData class for storing (internal) data required by the View class. - New getter/setter methods for ViewData properties for the View class. - New method Wireframe::getConfig() for getting current config settings. - New method ViewPlaceholders::has() for checking if a placeholder has already been populated. ### Changed - Various View-related features moved from Wireframe module and ViewPlaceholders class to the View class. - Removed access to local get* and set* methods via the PHP's magic setter method __set() and getter method __get() in the View class. - Redirect feature no longer fails if provided with a WireArray data type; in these cases the first item is used as the redirect target. - Improvements to PHPDoc comments. ### Fixed - An issue with Config class where the "all directories exist" message was sometimes displayed unintentionally. - An issue where View Placeholder values might've been overwritten because existence of earlier value was checked inproperly. - An issue where empty / null view file would be automatically replaced with value "default". On a related note, for this version I decided to give sonarcloud a try. For those who don't know it, it's a sort of a code quality inspector, and it's free for public projects. It didn't have a whole lot to complain about at this point, but it's good to have some sort of validation in place just in case. I will also be digging deeper into reported "code smells", as some of them definitely make sense to me ?

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.