Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by teppo

  1. Just to iterate on this answer: there's no built-in tag concept for pages in ProcessWire. If you want to add tags to your pages, you can a) use a Page Reference field for your tags (in case you want to define a collection of tags and reuse them), or b) use a text field (if you only need to use them for this one use case). The code @psy posted above depends on you first adding a Page Reference field called "tags" for your page, but note that you actually want to provide it with two params: $page->tags->implode(', ', 'title') (or name instead of title, or whatever field/property of your "tag pages" you want to display). On a loosely related note, the keywords meta tag you've mentioned is pretty much pointless these days. Search engines don't use it (at least as a ranking factor, although they may still include keywords contents in their index), and that was always pretty much the only reason to use it. Other than that tags can of course have valid use cases for categorising / grouping content πŸ™‚
  2. Sorry @Mike Rockett – got caught up with other stuff (surprise) and forgot about this πŸ™‚ I've just sent a merge request for WireCache support. It's an alternative to existing MarkupCache cache method, configurable via module settings. I've also made cache TTL (expire time) configurable: https://gitlab.com/rockettpw/seo/markup-sitemap/merge_requests/1. Let me know what you think πŸ™‚
  3. Thanks Bernhard! I might've indeed read your post somewhat wrong. Now that I've re-read it along with your comments (and watched the video), I think I have a better idea of what RockThemes is all about. I can even see some similarities with wireframe, although I'd still argue that they are few, and they seem to mostly apply to the view layer – or a part of it πŸ™‚ The word "theme" might've thrown me a bit off, yet now that I'm reading your post for the third time or so, I'm still not sure what else to call it. Correct me if I'm wrong, but technically you're talking about having the template files (/site/templates/*.php) populate a content variable, and the theme pretty much defines what "wraps" that site-specific content? Still not entirely sure I got this right, so I may be completely on the wrong tracks πŸ˜… By the way: as a bit of a disclaimer please don't take anything I say here as disencouragement. That is not my intention. I think your idea has plenty of merit, and it's thrilling to see projects like RockThemes that, in some ways, challenge the status quo. Trust me, I've been there. Your concern is perfectly valid and familiar. Site profiles are intended as starting points, and they don't scale beyond that πŸ™‚ One solution to your problem from my point of view: if you have a feature that you want to use on multiple sites either as-is (or perhaps with some modifiable settings), bundle it into a module. Menu generation, metadata output, favicon generation... this sounds like three separate modules to me. Or one module that does it all if that makes more sense, but at least in my experience separate modules tend to make more sense as they provide more flexibility. If it's all bundled into one package, you tend to run into problems if you want to modify your metadata generation method – but the modification only applies to, say, five out of those ten sites. Not to mention the two that require an entirely different solution, etc. The point is that in my experience it's better not to bundle too many assumptions into one package. "One module, one concern" πŸ™‚ (A bit off-topic, but the "small modules" approach can sometimes result in a more work when it comes to updates. That, in turn, can be resolved by using a module manager, or – my personal preference – Composer. Or, alternatively, Git submodules.) Even after re-reading your post, I still think that the purposes are somewhat different. Let me elaborate on that a bit... πŸ˜… For me one key point about wireframe is the separation of the business logic ("code", which is implemented as the methods of the Controller classes) from the presentation layer (the "dumb" views, partials, and layouts). The amount of markup generation features in wireframe is also exactly zero: it provides structure and "connects the dots" between different components, but the rest of the implementation is entirely up to the site in question. One example (I'm trying hard not to go too deep into my own "vision" here) are the sites I've built with the predecessor of wireframe that didn't have a "human-readable" UI. API first (or "headless") sites, that is. I've also built sites that didn't even have an API – only code that was triggered behind the scenes by scheduled scripts – though admittedly that's a rare use case. In wireframe controllers and various view components are all optional, which means that there may be sites that use them all, as well as sites with just a backend or just a front-end – not to mention that a site with a front-end may still use just a part of the view layer: all templates could use a single layout file for rendering, but they might as well not use a layout file at all and instead rely on template-specific view files for all their rendering needs πŸ™‚ Right – this makes sense, I think. I don't think I've yet seen in your examples how one would extend a theme, but I'm assuming that the general concept is that you've got one theme that you copy from project to project, and then for each project that differs from the base theme in any way you create another, site-specific theme that you customise? If that's correct, this reminds me of WordPress' themes and child themes. In that context the idea is that you can update the parent theme and your site will stay intact because all the modifications are in the child theme. (This, of course, doesn't always work because the child theme may override something that changes / breaks when the parent theme is updated, new version of the parent theme may add or change a feature that the site relies on / doesn't need, etc.) On the other hand RockThemes itself is more like a "theme frameworks" in that it provides the base implementation for themes to build on, and possibly a number of general purpose helper features, components / blocks (?), etc. Hard to say what those would actually be without seeing the module, so I could be on the wrong tracks again, of course. I'll have to give this a few more moments to really sink in, after which I might have more questions / suggestions. Anyway, If I'm following you correctly, I like what you're doing here but wouldn't personally go this way – partly because I'm already invested in wireframe (obviously), but also because this doesn't seem to solve the issues I mostly struggle with (such as the part about separation of concerns). The issues with updating stuff, on the other hand, I've managed to resolve via other means, so for me that's mostly a non-issue πŸ™‚
  4. Hey Bernhard! A few initial observations and notes – I will have to dig into your post deeper and check the video when I'm back home. On a trip at Spain at the moment, and the network connection here is... limited πŸ™‚ First of all I still find the idea of themes intriguing, but it's also a complex matter, and there are different aspects to consider. For an example WordPress has (as most here probably know) made great effort to support themes – yet in reality you cannot just switch between themes as you want (which is, in my opinion, a key point in the themes vs. starting profiles discussion) if you have something "out of the ordinary" going on: custom fields, custom views, plugins generating markup, etc. Wireframe doesn't actually try to solve the theming part. In fact it's quite the opposite: it's a framework that provides sensible structure for sites built with ProcessWire – one that separates the implementation into different files/classes ("business logic" vs. views vs. layouts and so on) in a meaningful way, allows for reusability, and continues to make sense even if/when the site scales. While it can be easy to make visual changes to a site built with wireframe – as long as it's used in its entirety, in which case making changes to a single layout file is often all you need – that's really the extent of it. The kind of things you've mentioned, like getting the framework and setting things up, are in that context resolved with site profiles: if you find yourself repeating these tasks over and over, you should build a site profile where you've got the defaults nailed down – or, if you find you often just swap the logo etc. then add a settings area and a custom field for it. The "official" Wireframe boilerplate is one of those, and here at Avoine we've got our own "boilerplate" specifically tailored for the type of sites we work with (and what you've listed are (some of the) things we've covered in it). Long story short: I think we're solving different problems, and as such I wouldn't draw too many lines between those two solutions πŸ™‚ I do agree that you're onto something here, though, and see a need for that. The way you've described RockThemes sounds pretty close to how WordPress works, although I've not had the chance to dig into all the details yet. For an example I don't have a good idea about how much you're planning to let a specific theme override vs. how much you plan to keep things "set in stone". That, I think, is actually one of the most important factors here: figuring out how much you can/should standardise stuff, and if one can "break loose" of the theme by overriding it in a way that changes it radically. ... and that, of course, depends on how far you want to go in terms of "themeability": if one wants to switch a theme and it should always "just work", you might go as far as define basic views and features (such list and archive views etc.) so that theme authors know what to provide markup/logic and styles for. On the other hand if it's enough that the layout is interchangeable and all content types (templates) that don't follow some specific convention (title and body fields, or something like that) will need per-site markup, then a much simpler approach is going to be quite enough. My "a few initial observations" got a bit out of hand, but I'll definitely check the video etc. later. And sorry if I've missed any important points here πŸ™‚
  5. Sorry for the late reply. This is definitely something I'll have to figure out, one way or another, just haven't had the time (or need for that matter) yet. I'll have to do some testing first and get back to this later πŸ™‚
  6. Couple of updates during the past week, 0.11.0 and 0.11.1. I'll attach the changelog below, but here's a summary of changes: Saving just a single field (via API or perhaps some async feature) should now correctly regenerate the search index. Page Reference fields are supported: the title and name values of referenced pages are stored in the index. Page names can also be search with the field name; if, say, you have a Page Reference field called "tags", you can find specific matches by searching for "tags:[tag-name]" ("tags:tailwind" etc.) One relatively big change behind the scenes is that now the search index is generated after page has been saved, by hooking into Pages::savedPageOrField and triggering a new save for just the index field, quietly and with hooks disabled. Originally the module hooked into Pages::saveReady and generated the index so that it got saved along with any user-provided changes, but it turns out that this could result in some rather obscure bugs due to output formatting being enabled on the fly (which is intentional, and required for the most representative search index) which in turn was triggering interesting side effects under some specific conditions. So far the new method hasn't resulted in any unexpected side effects as far as I can tell, but it's worth pointing out this is a pretty big update. ## [0.11.1] - 2019-09-26 ### Changed - Index value gets saved in Pages::savedPageOrField instead of Pages::saved. ## [0.11.0] - 2019-09-26 ### Added - Support for indexing Page Reference fields. - Support for indexing non-field Page properties (id, name). - New hookable method Indexer::___getPageReferenceIndexValue(). ### Changed - Index value gets saved in Pages::saved instead of Pages::saveReady so that we can avoid messing with the regular save process. ### Fixed - Fixed the "save" behaviour of the Indexer::indexPage() method.
  7. Assuming that I correctly understood your need, this would require dynamically generating the descriptions. Technically it should be doable by hooking into Renderer::RenderResultDesc(), but you'd have to provide the entire description generation and highlighting logic yourself, so it might be a bit difficult to achieve in practice. This is actually something that I've got planned, but I'm not really sure when I'll get to it. Anyway, it's good to know that there's demand for it.
  8. AdminBar 2.4.0 is out and adds support for the "data-adminbar-adjust" attribute. The idea here is to automatically modify (or adjust) certain CSS properties whenever the height of the Admin Bar is recalculated. Note: AdminBar already automatically adds "padding-top: [Admin Bar height in px]" to the <html> element, so this feature mainly applies to elements with "position: fixed". Assuming that Admin Bar is displayed and is 100px tall at the moment, the following markup... <div data-adminbar-adjust="top max-height"></div> ... would result in this: <div style="top: 100px; max-height: calc(100% - 100px);" data-adminbar-adjust="top max-height"></div> Thanks to @Fokke for the idea πŸ™‚
  9. Sorry, I've got nothing for this. At this point my suggestion would be to keep those packages in the repository. It's the only way that works seamlessly with the module installer in Admin, and I believe it makes more sense for your module than any of the alternatives I can think of. Anything else would reduce your potential user base significantly. I've gone the other way with some of my projects, but those have mainly been site profiles, so the context is quite different. While I agree that a native Composer installation integration could be nice, we're not quite there yet β€” at this point requiring Composer may make sense for hard-core developer-oriented projects, not much else. Go for it! I've been putting out PHP 7.1+ content for a while now, and so far no complaints. It's perhaps worth noting that PHP 7.1 is well on its way to being obsolete as well: it's already past the active support phase, and in just over two months it will stop receiving security updates. While certain organisations may backport security fixes for 7.1 for a while after that, officially its really close to the end of its lifespan. Folks should be already using (or at the very least actively updating to) 7.2 – or preferably 7.3 πŸ™‚ Again: go for it πŸ™‚ I don't think that this will affect a particularly large portion of users (last time I polled this was in 2017, but even back then ~55% of those responding were already on 3.0), 2.8 itself hasn't been updated for almost three years now, and users of legacy versions can always keep using one of the solutions that work for said legacy setups.
  10. So true. It's a nice idea, but CSS content is indeed problematic. Sometimes you want to add otherwise meaningless (visual) content (like icons) with CSS content and it turns out that some screen readers read them out loud, which can be quite confusing. There's no aria-hidden for CSS content, so reliably hiding said content from screen readers can be a real hassle. On the other hand there are times when you actually want to provide content for screen readers with this technique – yet it turns out that some of them will happily disregard it. In my experience it's almost never a good idea to add content with CSS πŸ˜…
  11. 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 πŸ™‚
  12. 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 πŸ™‚
  13. One more: I'm also seeing this error for the 'user_agent' column.
  14. 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.
  15. 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) πŸ™‚
  16. These sound like a good addition to rule 5B. Blocking access to known sensitive files is exactly the point of that rule πŸ™‚
  17. 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.
  18. 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.
  19. 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.
  20. 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!
  21. 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 πŸ™‚
  22. 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 πŸ™‚
  23. @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 πŸ™‚
  24. 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.
  25. Moderator note: this thread was moved from "Modules" to "General Support", as it's a question about a core module.
  • Create New...