teppo

Hey @DL7, just a quick heads-up: I've merged your questions into the support thread for the Admin Restrict Page Tree. The modules/plugins area of the forum is intended for module-specific support threads (one per module), and you can find the correct thread via the modules directory.

Hey @Mike Rockett. I'd be happy to try, if you're busy. I've got a need for this in one of my current projects anyway 🙂

Just for the record (not saying that it would be the best solution overall), FieldtypePageIDs also has certain benefits if/when the problem is loading too many Page objects into memory. It could be worth looking into in this sort of situation 🙂

Another +1 from here. If a module I maintain works for something other than Uikit then that's brilliant – but if it doesn't, I won't lose any sleep over it. For quite a while I used to support the "legacy" theme, new default theme, and Reno theme, but that was a major headache. There will no doubt be sites running those older themes for quite a while, but my guess / gut feeling would be that a notable portion of those are older sites that probably aren't that actively developed anyway.

Hey @Mike Rockett! I'm wondering if there's some way to add support for URL segments in the module. Any chance you might've figured this out already? 🙂 Basically in my use case there are pages that list items below them, yet those items actually live outside of the publicly viewable page tree. It's a no-brainer that they wont work right out of the box, but what I'm wondering is if we could somehow – hook or some template setting or something – inform MarkupSitemap of these "non-pages", and add them to the sitemap. I had a quick look at the codebase, and I'm wondering if this could be achieved by an optional hook in MarkupSitemap::addPages, perhaps by passing $page and $url to a hookable method after calling $this->urlSet->addUrl($url)? Seems that this way I could add a custom round of iteration and also add those URL segments as new URLs to the URL set 🙂

@Mike Rockett, sorry to bother you with this again, but with version 1.5.56 of Jumplinks we're still seeing quite a few database errors: Looking at the database the column is now varchar(512), but it seems that's just not enough. On a related note: on this site "Log 404 hits to the database" isn't checked, so I'm wondering why this is still happening? This is unrelated to the database issue above, but it also seems that there might be some unnecessary / unexpected process going on in here 🙂

If you're using the code you posted earlier, i.e. "$results = $pages->find(...)" and "$out.= $results->renderPager()", SearchEngine settings won't kick in at all. This is plain old native ProcessWire stuff, so you'd have to provide pager settings directly to the renderPager() method 🙂 SearchEngine pager_args only apply if you're using it's native rendering features. Though please let me know if I'm missing the point here!

Hey @guy, thanks for sharing this! Unless I've missed something important, note that your module doesn't actually have to hook into WireMail::___send() – it's a WireMail module, so it should implement its own ___send() method instead. This is how WireMail modules are designed to work, and it also guarantees proper interoperability in the case that other WireMail modules are installed 🙂 See WireMailMailgun for a reference.

Just released SearchEngine 0.13.0. This version adds more validation regarding the search index field: there's a warning if the field is of wrong type, an option to automatically create it if it doesn't exist (i.e. it has been removed after the module was installed), and there's a notice in the module settings screen if the index field exists and is valid but hasn't been added to any templates yet. Additionally there's a fix for an issue where FieldtypeTextareaLanguage wasn't recognised as a valid index field type in module settings. This could've resulted in the index field setting getting unintentionally cleared if/when module settings were saved.

The trick is to whitelist "q", after which MarkupPagerNav automatically sticks with it. Add this after you've validated the $q variable: $input->whitelist('q', $q); Note also that if this is your literal code, you should move the renderPager call in the if statement – if $q isn't set or validated, $results will be null, and this will cause an error 🙂

@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 😕