teppo

Hey @iipa – just a quick heads-up that I've moved this thread to the General Support area of the forum. Modules/Plugins area of the forum is dedicated for (third party) module support threads (of which there should be one per module), and this question is about a core module/feature 🙂

Hey @martind, just a heads-up that I've moved this topic to the General Support area of the forum. Modules/Plugins area is only intended for module-specific dedicated support threads (for third party modules), and this question is about a core feature 🙂

@buster808, just a heads-up that I've merged your question to the Markup Simple Navigation support thread. When you have questions regarding an existing module, you can find the module-specific support forum thread from the modules directory entry for that particular module 🙂

I think that's just about it: 62k is ~20% of 311k, so the conversion has shaved off 80% of the size of the original source image. Kind of seems to me that in this context displaying the size of the WebP image in comparison to the source file (20%) could've made more sense, but I guess it depends on how you like to think about it 🙂 About deleting a WebP variation – I've no idea.

I realise it's been a while since this was posted (again: sorry!) but while some sort of email trigger might be an interesting future addition, at the moment what Adrian suggested is probably the fastest and easiest way to achieve this. That, or perhaps Field Change Notifier in case you prefer a GUI solution 🙂

Latest version adds support for ignoring specific users and/or roles, so that may help a bit. There's no clean way to figure out what is a system action, so I think ignoring the guest user (or some other user/role you use to perform these automated actions) is the best solution we have at the moment. Shorter duration for log rows matching some rule (such as a specific role/user) could be a potential future addition as well, in case there's demand for that sort of thing 🙂 It's been a while (sorry!) so hopefully this has been resolved already. If not, let me know (preferably via GitHub issues, these are much easier for me to keep track of). If this is still occurring, please open a GitHub issue (if possible). I've just tested the module with both Reno and (old) default admin theme's, and was unable to reproduce this. I'm not entirely sure of the specifics, but it seems that adding any published (and non-hidden) page under /processwire/setup/ brings it up in the menu, so not really sure where to start, except that perhaps make sure that you're not using any hooks / modules that might somehow alter menu behaviour. It would be best if you could try this on a blank install: if the issue occurs there, it should be much easier for me to reproduce as well. If not, it's probably something specific to your current setup, which means that we'd have to start by figuring out what exactly is going on there 🙂 Latest version (1.7.1) has two new configuration options (ProcessChangelogHooks config settings): ignored roles and ignored users. I think one of these should help with this 🙂

Hey franciccio! I may have misunderstood your post (in which case: sorry in advance) but if by "I can't put them in processwire" you mean that you can't add keywords with ProcessWire, then please re-read the posts in this topic. As Bernhard and psy both pointed out, it's actually quite easy to do – the only thing you need to do is add a custom field for your keywords. There's no native keyword field out of the box because, let's face it, very few users need that. That being said, if you want to have a field for storing and outputting keywords, all you need to do is add it yourself. Just like you would with any other custom data you require 🙂

Latest official statement is from '09, but nothing I've heard since has convinced me otherwise. Experts in the subject seem to concur. There have even been some suggestions that it may be harmful – though of this I also have no experience myself, or perhaps I was always using it in a "non-spammy" way 🙂 Latest advise from Moz states the following, classifying the keywords meta tag as "indifferent": The folks at Yoast even went through the trouble of removing the support for meta keywords from the Yoast SEO plugin, though I believe their reasoning was mostly just that people were spending time thinking of good keywords to put there, while in reality it was all wasted effort.

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 🙂

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 🙂

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 🙂

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 🙂

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 🙂

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.

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.