Jump to content

teppo

PW-Moderators
  • Content Count

    2,492
  • Joined

  • Last visited

  • Days Won

    65

Everything posted by teppo

  1. 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.
  2. 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 πŸ™‚
  3. 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 πŸ™‚
  4. 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.
  5. 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 πŸ™‚
  6. @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 πŸ™‚
  7. 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!
  8. 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.
  9. 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.
  10. 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 πŸ™‚
  11. @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.
  12. This is on the top of my to-do list now πŸ™‚
  13. 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 πŸ™‚
  14. 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().
  15. teppo

    SeoMaestro

    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 πŸ˜•
  16. teppo

    SeoMaestro

    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.
  17. 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 πŸ™‚
  18. 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 πŸ™‚
  19. 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.
  20. teppo

    SeoMaestro

    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 πŸ™‚
  21. 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? πŸ™‚
  22. 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.
  23. 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 πŸ™‚
  24. 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.
  25. 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 πŸ™‚
Γ—
Γ—
  • Create New...