teppo

Based on the Modules class it looks like module versions are checked by Modules::checkModuleVersion(), which gets called when individual modules are initialized (Modules::initModule()). From here on I'm largely guessing, but what I'd probably try first would be iterating over all modules (assuming that you want this to occur for all of them) and then calling something along the lines of... if ($modules->isInstalled($module_name_or_class) { $modules->get($module_name_or_class); } ... for each of them — first check is just to make sure you don't accidentally install all modules, while get should trigger upgrade check (if I'm correct, that is) ? Sounds a little hacky, not sure if it'll work 100% or if there's a more straightforward way. I couldn't spot one, though.

I'm not sure I fully understand what you're trying to achieve here, but no — this is not something SearchEngine does. It creates a single index for the entire site. I have considered adding support for multiple indexes, but a solid need for that never surfaced. Would be interesting to hear if there's one now, though admittedly this seems more like a need for a custom search engine, and thus likely has little to do with this module. The TL;DR seems to be that "this is not the module you're looking for", but I'll go through your questions just to clarify things: I'm not entirely sure what you mean by adding custom operators. If you're referring to selecting some operator that isn't available via SearchEngine settings, that's possible, but to be honest most of the selectors that make sense within site search queries are already there. As always it's good to read the docs, though; understanding selectors and selector operators is a key factor when working with ProcessWire ? Anyway, the settings you see in this screen are defaults. Most site search tools don't let visitors select operators or even alter the sort order in any way, so setting them once here is enough. If you're working on something more complex — perhaps something like library databases often provide — these settings have little to do with that. In this case you're probably not going to have much use for SearchEngine, although it's of course possible to create a custom search feature and use the search_index field as a regular field in your queries. At the moment you can't. These are not fields, they are indeed (literal) table columns. Search Engine doesn't work on that level. It'd be possible to add this feature, but at the moment this seems like an extremely rare need, and as such it's not particularly high priority. The selector inputfield you see when you use "Index pages now" feature is only a tool for finding the pages you want to index, and it's using the core Inputfield Selector for selecting applicable pages. The first part is not really in the scope of SearchEngine: it's a tool for providing a site search, and since sites consist of pages, that's what it will list. It does indeed sound like you're looking for something more customized. ... although you can in fact a) completely skip any front-end markup generated by SearchEngine and provide your own instead (basically just use the search_index as a regular field in queries), or b) modify markup generated by SearchEngine using hooks, or even c) hook into the indexing process to fill in other custom fields in addition to the default search_index field. All of these would require plenty of custom work, and I'm honestly not sure if you'd find SearchEngine useful for your needs; you may find it easier to build the entire thing from scratch.

Sure, it should work just fine. Let me know if you run into any issues though!

PHP 7.4 here as well. So far I can't remember having any major issues going from 7.1 to 7.2 and then 7.4. Most sites I run are relatively up to date, though, and generally speaking I don't use that many third party modules either. To be honest if there's any reason to worry I'd recommend 7.4, or perhaps even 7.3 (it's still supported for a while and would give some extra time to prepare for a bigger jump.) Probably going to set up a new server on weekend and move some sites there. Might as well go with PHP 8 and see how that goes ?

This is a long shot, but you should start by making sure that file WireDatabasePDOStatement.php exists in /wire/core/. It could potentially be an issue with one or more missing files, so getting a new copy of the wire directory could be a good idea as well.

Just checking: TextformatterVideoEmbed is listed before TextformatterPrivacyWire? If it's the other way around, this won't work. This could potentially affect the situation. I would make sure if it makes difference, i.e. try disabling it and see if that changes anything. So far this has worked for me, but let us know if the issue persists ? Edit: if TextformatterVideoEmbedOptions runs before TextformatterPrivacyWire, this will definitely break things due to this line: https://github.com/blaueQuelle/privacywire/blob/master/TextformatterPrivacyWire.module#L51. Seems like an easy fix, though. Admittedly the order of the modules is a bit fragile, but part of it is really due to the way textformatters work and there's not much that can be done about that.

Thanks — this is now fixed as well ?

@adrian, that PHP 8 issue should be fixed now. At least I assume it is — still don't have PHP 8 test environment, so it would be great if you could give it a try and let me know how it goes ?

Thanks for reporting this, @adrian! The issue is clear (return types for magic methods are now enforced by PHP) and the fix is simple, but I'll have to set up a test environment to make sure it really fixes the error... and doesn't introduce any new issues ? I'll get back to this ASAP. Edit: the dev branch at https://github.com/wireframe-framework/Wireframe/tree/dev now contains a fix for this, if you'd like to give it a try. I'll have to test this properly before merging to master.

You can find a live example of this from https://github.com/blaueQuelle/privacywire/blob/master/PrivacyWireConfig.php: $f = $this->modules->get('InputfieldText'); // ... $f->useLanguages = true; (Here it's a text input, but this should work for textarea as well.)

Just a quick heads-up: https://www.php.net/releases/8.0/en.php. PHP 8.0 is out. Some pretty fancy new features there, really looking forward to getting my hands on this one ? Might be a good idea to test before updating any critical environment, though. As always there are some backwards incompatible changes etc.

Just to be clear: in my opinion it's actually perfectly fine to perform redirects in Apache config files, site-specific vhost files, or even in the .htaccess file. It's just that they should use RewriteRule (mod_rewrite) instead of Redirect (mod_alias). If a new site requires redirects for old URLs, this is typically how I handle it — this way I have full control over wildcards and such, and there's very little overhead. Nothing wrong with using Jumplinks (or ProcessRedirects), of course. That slight overhead they add (booting up ProcessWire, checking for redirects, etc.) rarely matters ?

This "it" variable where ProcessWire internally gets the requested URL, see https://github.com/processwire/processwire/blob/master/wire/modules/Process/ProcessPageView.module#L320. If you're seeing these in your redirects, it probably means either that this Redirect is after ProcessWire's initial htaccess rules, or alternatively that Apache doesn't stop processing the htaccess file when it finds the Redirect row. I'm not completely sure if Apache should stop at Redirect or not, so you may have to use RewriteRule instead, specifying [R,L] as flags. Edit: gave this a quick try and it seems that there's no obvious way to make Apache stop parsing further rules when Redirect occurs. Simply put RewriteRules should be used in this situation instead — or you can use a module / code approach, which of course comes with some overhead. Overall mixing mod_alias and mod_rewrite seems like a bad idea ?

While I kind of share your opinion on the vendor lock-in thing, I don't think this is going to be a big deal — as Ryan pointed out the vast majority already use GitHub, even though some popular modules are currently on GitLab. Looking at this from Ryan's point of view it's likely less work to develop (and maintain) features when you're using a single API rather than multiple... and if that helps Ryan keep things up and running, I think it's a good approach. Also personally every time I want to report an issue or send a pull request (or merge request in GitLab) it's a bit of a nuisance if the module is not hosted on GitHub. What I'm trying to say here is that since GitHub is the most popular option by far, as well as the platform we're using for core development, hosting third party modules there makes collaboration easier ? Regarding "own git" or "custom download URL" it's good to keep in mind that a lot of the data can be pulled automatically via GitHub API, and this would defeat that purpose. Custom download URL would also be potential risks in terms of security — public git repository, and preferably one with a GUI, is a must-have for this exact reason.

Awesome — thanks Joshua! Just a heads-up: I've opened a new PR for you to check out at https://github.com/blaueQuelle/privacywire/pull/10. This is quite opinionated, so let me know if you don't feel it's a great match with the module. Basically what I've added is support for the textformatter module to replace embedded media/video iframes with PrivacyWire enabled ones. It's mainly a compatibility layer for TextformatterVideoEmbed ?

Hey @joshua! I'm not sure if this is a real bug, but on one site I have a script like this: <script id='taeggie-feed-widget-script-xxx' type="text/plain" data-type="text/javascript" data-category="marketing" data-ask-consent="1"> jQuery.getScript(...); </script> This works and the consent info/request box is displayed. If I click the "accept" button from this info box it goes away and the script gets executed, so all is good in that case — but if I instead click the "accept all" button from the (separate) cookie management banner, the info and accept button next to the script are not removed. Note that the script works as expected regardless of which accept method I use, so the only issue here seems to be that the info box / accept button are not removed. If I refresh the page, they are gone. Is that a bug, feature, or user error? ?

Hey @Ivan Gretsky — thanks ? With latest version (just released, 0.27.0) you can make the module store page ID as an indexable field. This will allow the page to be found by its ID (since that is now included in the index) OR you can use syntax such as page.id:1234 to specifically search for a page with this ID (though this would likely also match page.id:12345 etc.) Of course id:1234 will also work, but may result even more false positives. If you update to the latest version of the module, note that you also need to add id as an indexable field and rebuild your index before this will work.

Just checking: do you have VersionControl module installed? Core doesn't (as far as I know) have this kind of error anywhere, so it could be a third party module (and VC is one module with that exact error message) ?

New release — 0.18. This version adds Tracy panel for Wireframe: Obviously the panel will only show up if both Wireframe and Tracy are installed. Currently it displays some content I thought could be useful while developing, but I'm open for suggestions. Tracy doesn't really enforce any rules here, so in the future the panel could also provide interactive developer tools or something along those lines... just not sure yet what would be useful ? Thanks to @adrian for adding support for custom panels!

Looks like someone (apparently a single user) has been going around forums and vulnerability databases posting about a ProcessWire "local file inclusion" vulnerability, claiming that in a specific old version of ProcessWire (2.4.0) simply passing "download" GET attribute to index.php is enough to download any local file on the system, including files that may be outside the ProcessWire installation path. This is not a real ProcessWire vulnerability — this kind of argument has never existed in any version of the system. Simply put the report is either fake, mistake, or there could be some custom-built vulnerable piece of code (or other vulnerable software) on the host resulting in this behaviour. We take such claims seriously, however unlikely they may seem, so just to make sure I've just checked parts of the codebase in both 2.4.0 (where this is supposedly occurring) as well as various later versions, and there's zero evidence to back this claim up. I've also manually tested this on various setups, including a brand new 2.4.0 installation, to no avail. (Note: I wouldn't post about this here unless the original claim was relatively widely spread. Just felt it made sense to clear things up.) --- That being said: as one builds sites using ProcessWire (just like with any other system) they need to be careful not to introduce vulnerabilities of their own. ProcessWire is armed with brilliant tools for preventing common vulnerabilities — the selector engine helps avoid various SQL issues, Sanitizer has many tools for cleaning up dirty data, SessionCSRF makes implementing proper CSRF protection downright trivial, etc. — but it can't protect you automatically from every mistake ? More security tips: https://processwire.com/docs/security/.

This is intentional; specific system pages are by default only displayed to the superuser role. Trash is a special case that may be displayed to non-superusers as well. Whether this decision makes sense is, of course, another question. In my experience it has been a good thing, and I've never personally come across a reason to display the Admin area to non-superusers that wouldn't be better solved in some other way ?

For the record I've merged your question to the Markup Load RSS support thread. The Modules/Plugins area of the support forum is dedicated to third party module support threads, one thread per module — please try to post your questions to the applicable thread if one exists. Thanks! Here's one of the examples from the first post in this thread: <?php $rss = $modules->get("MarkupLoadRSS"); $rss->limit = 5; $rss->cache = 0; $rss->maxLength = 255; $rss->dateFormat = 'm/d/Y H:i:s'; $rss->load("http://www.di.net/articles/rss/"); echo "<h2>{$rss->title}</h2>"; echo "<p>{$rss->description}</p>"; echo "<ul>"; foreach($rss as $item) { echo "<li>" . $item->title . "</li>"; } echo "</ul>"; It seems to me that this example is doing pretty much exactly what you asked, i.e. it loads a feed using this module and then outputs the title of the "channel" element from the feed, as well as a list of found items. Please let me know if I misunderstood your question, though.

To be fair I believe we're on the same page here, except for one detail: those modules — Seo Maestro and Markup Metadata — are actually two very different solutions. In fact what you're describing is exactly why we use Markup Metadata by default in our projects: there's no GUI, and a big part of the markup is based on globally defined values or values from (pre-existing) page fields. It's just a markup module for handling the repetitive task of rendering a standard set of metadata elements, correctly and consistently, from project to project. That being said, in my experience some people prefer a more complex approach, either because they actually need it or because they think they do — and if a client was specifically requesting feature set similar to that of Yoast, a solution such as Seo Maestro might be just what you need to convince them that they don't need to go with WordPress just for that ?

Same. I also tend to bundle these with fields for open graph metadata, option to override page title separately, and whatnot. You might want to check out module solutions if you haven't yet. Seo Maestro is a neat one, and MarkupMetadata is what we use for our web projects (though latter one doesn't provide a GUI for content editors, it's just for generating proper markup). My experience is similar: the content analyzing features of Yoast have never been particularly useful for me, in part because I've mostly worked on non-English sites where they don't seem to work so well. Also these reports seem to — at best — provide a rough estimate of how good your content might be, and (in my opinion) there are better tools for that. If your clients are often interested in doing "hardcore SEO", I'd definitely dig into external tools and see if there are some that you can recommend instead. Yoast has some nice features for working around WP's shortcomings, and I've found their "helper" tools (such as breadcrumb creation) pretty handy in the past. ProcessWire, on the other hand, makes things like breadcrumbs and canonical links trivial, and the structure is often so straightforward that you don't need to do a whole lot to make your site "SEO friendly". One thing to note is that Yoast actually does handle "modular pages" relatively well. Last I checked it required a separate plugin and only worked if your content was all visible in the editor, though. My understanding is that it just mashes it all together and then does its magic. Crude perhaps, but in many (if not most) cases this provides decent results ?

Awesome! ... well, not awesome that the DNS was messed up, but you know, awesome that they got it solved — eventually ?