teppo

@ceberlin @3fingers As of 0.12.0 SearchEngine now supports multi-language indexing and searching. This is based on the native language features, so the results you see depend on the language of current user etc. While I don't have a good test case at hand right now, I did some quick testing on one of my own sites and it seemed to work pretty much as expected – though please let me know if there are problems with the latest version ? What you need to do to enable this is convert the index field (which is by default called search_index) from FieldtypeTextarea to FieldtypeTextareaLanguage.

This is on the top of my to-do list now ?

Hey Bernhard! SearchEngine already provides a way to highlight hits found from the generated summary, but since there's currently no built-in way to show dynamic summaries on the search page, this doesn't apply to the entire index. See here for an example: https://wireframe-framework.com/search/?q=wireframe. Please let me know if I've completely misunderstood what markjs does – I'm interested, but not quite sure if it would be beneficial, and/or how it would differ from current situation ?

Just released Wireframe 0.7.0. This version is all about caching: when requesting Controller methods from view (<?= $this->some_controller_method ?> etc.) the return value is now cached (runtime cache). Additionally if method names are added to protected $cacheable_methods property of the controller class, along with an applicable expire time (i.e. "protected $cacheable_methods = [ 'method_name' => 3600 ]"), Wireframe automatically caches the value using WireCache (persistent cache). Caching is usually a good thing, but not always preferred, which is why runtime caching can be prevented by adding the method name to (protected) Controller property $uncacheable_methods (protected $uncacheable_methods = [ 'method_name' ]). Persistent caching is always opt-in. Changelog: ### Added - Runtime caching support for Controller method return values. Values are cached *unless* the name of the method is found from Controller::$uncacheable_methods. - Persistent caching support for Controller method return values. Values are cached only when found from the Controller::$cacheable_methods array. ### Changed - In the View class all internal requests for Controller properties are routed through View::getFromController().

Well, this likely rules out the first issue I was thinking of. There are still two possible explanations: either sitemap generation fails, or writing the sitemap file to the disk fails. I'm not particularly familiar with this module, so all I can suggest at this point would be dumping some debug data out of SitemapManager::generate() function; basically checking if the !count() statement is returning false (in which case there are no items, which in turn would warrant further investigation into why that would happen), or if it's the write operation that is failing. You should also double-check that the path on disk (the root of your site, essentially) is writable for the user running Apache (often www-data, but could be something else, depending on your setup). Edit: I installed SeoMaestro on a new site running the latest dev version, and everything worked as expected. I know this won't help much in this case, but at least I can confirm that the module should work, which means that the issue is likely somehow related to your environment, or the specifics of your site ?

Do you have a SEO field (FieldtypeSeoMaestro) added to at least one of your templates? I can't remember if this was always a requirement, but without that the module won't generate a sitemap, and thus it will output that specific error message. This error is a bit misleading: it recommends checking that the folder on disk is writable, but you'll get the same error even if you simply didn't have any items to add to the sitemap. What's happening here is basically that the module attempts to generate a sitemap with SitemapManager::generate(), which returns false if it fails to write the file, but also if there are no items to be found. Ping @Wanze – might be a good idea to add additional check for this ? If you do have the SEO field and the write permissions are fine, I'd probably try debugging the sitemap generation code in the SitemapManager class, just to see if it's working as expected.

On a loosely related note: in case you already serve your content via HTTP/2, combining files is often less important. In some cases it may even be the opposite: technically the optimal use case would involve combining JS files into separate, smaller bundles that contain related features. "One big blob of JS" is very close to an antipattern these days. Just my five cents. Overall what I'm trying to say here is that if you're using HTTP/2 (which you should – and if not, that's something to focus first anyway) I wouldn't worry too much about bundling files, unless you've got loads of them ?

Hey @ryan! I'm not sure if you did something special last week to get the Packagist dev-dev branch updated, but either way it is now serving 3.0.143. The problem is that this is the version right before the "Operator '&' is not supported" issue was fixed. I was hoping that releasing 3.0.144 would again update Packagist, but it didn't, which means that installing ProcessWire dev branch using Composer via Packagist currently results in a bugged version. If you did do something special last week in this regard, it'd be awesome if you could do it again – and if not, a manual "update" at https://packagist.org/packages/processwire/processwire might be in order, or at least that could force Packagist to fetch the latest version ?

Moderator note: this thread was moved to "General Support". Modules section is intended for dedicated third party module support threads only, and this question is about a built-in core feature.

Hey @psy. Just a heads-up that I've merged your post to existing seomaestro support thread. Hopefully someone here can help with the issues you're experiencing ?

I have no experience with the blog module(s), but if a hook method attached to ProcessPageView::pageNotFound doesn't get executed at all for /blog/ URLs, this likely means one of two things: either there's no 404 exception when the user visits those URLs (i.e. the template of the page at /blog/ has URL segments enabled, but it isn't throwing 404 exception when a non-existing URL segment is accessed), or the module itself has some hook that prevents this from working. The first option seems more likely to me, but again I don't have any experience with this module, so can't say for sure. This could also be by design, so maybe @kongondo could step in and see if he has an idea about what's going on here? ?

Yes, you'll still have to somehow upload the files of your site to the server. The main difference would be that you don't have to copy-paste markup from HTML files to PHP files and change paths or anything like that, as the site you're developing locally is essentially identical with the one you have online.

Hey, Not a direct answer to your question, but rather a suggestion for a better workflow, as I can see that you're getting yourself into a bit of a mess here – and I think it can all be avoided. This is apparent from the questions you've been posting lately, and as such I really think you should rethink your approach. Basically it seems to me that you're developing a site as a static HTML website, and then on each "server push" transforming it manually to a ProcessWire site, converting HTML files to PHP template files etc. What you really should be doing instead is developing the site locally as a dynamic one – this is pretty much the only workflow that will work well without going through a lot of manual work, or setting up a very complex and fragile transformation process. In other words: set up a local development environment using WAMP (or something similar), install ProcessWire on it, build the site, and then push it to the production server. This way you don't have to worry about any of this tricky transformation stuff, or the resulting stress. Yes, it may take a while to set up (an hour or two even, if you've never done this before) but it's absolutely worth it ? -- A more direct answer: I don't think that what you're suggesting will "hurt" ProcessWire in any way. If you only upload a new folder to the root of the site, that's fine – just be careful not to accidentally remove this directory yourself if/when you update ProcessWire ?

I haven't had the chance to see this in action yet, but looking at the code I'm wondering about one thing: at least in my case it's often important to know exactly when a particular issue first occurred, so that I can figure out what might've caused it – but if that initial occurrence is now removed, doesn't this make that process difficult, if not impossible? My initial thinking is that perhaps we should also store the timestamp for the first occurrence along with the counter data. That would, in my opinion, be an improvement over just logging the latest case along with a counter. While debugging a strange issue it's sometimes also helpful to know about the exact timestamps of all occurrences, but then we're basically back at not having this feature at all ? Overall I can see value in this, particularly from the UI point of view and for those cases where you're somehow spammed with a truckload of identical log entries, but I'm also a bit concerned that it could make debugging problems harder. As such, it might actually be a good idea to allow disabling this feature altogether; this way users could still opt-in for "full logging" instead if that works better for their workflow.

Equally OT, but it sounds like this could result in unwanted consequences: PagePathHistory hooks into ProcessPageView::pageNotFound, so initially it only knows that a Page is missing. If it doesn't have a record for that exact URL, the most straightforward approach for supporting URL segments (as you've suggested) would mean that it needs to recurse through the path and see if it can find a record for a partial match for a Page that has URL segments enabled (which is getting somewhat complex, and creates a bit of overhead), and – since ProcessWire can't really know for sure which segments are available, let alone were available in the past – it would probably just have to assume that anything goes. In addition to the overhead and general unreliability, it also sounds like this could create redirects for URLs that should just throw a 404, and we'd also have some new questions: is it enough to check if the target page currently has URL segments active, or should we assume that this may have changed as well? What about the redirect – is it enough (i.e. helpful) to redirect to the parent page, or should it attempt to redirect to an URL segment on that page? If we do that and it fails, what next? All in all I can see a number of potential gotchas here, so not supporting URL segments seems like a reasonable decision. They are "virtual paths", and PagePathHistory is for real paths ?

Have you tried Repeaters? This sounds like a good use case for those: each repeater item would include a body field (and possibly a header), and thus you don't have to add lots of individual "body fields" to your template(s). Google doesn't care (or know) about your template structure, it indexes what it sees on the page. If the (rendered, final) page contains specific piece of content, it will likely get indexed by Google. Same answer here: Google doesn't know anything about your templates, it only sees your (public) pages and the content on those, and that's what it's going to index.

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 ?