Leaderboard

Continuing from last week's post and discussion, ProcessWire 3.0.218 decouples the modules system from the cache system. Now the modules system maintains its own internal caches (at least once you do a Modules > Refresh). It'll still use the $cache API as a backup (temporarily), but now you can safely export the database without the "caches" table, or even delete the "caches" table, if you want to. It'll get re-created as needed. In this version, work also continued on the new WireCacheInterface (and major updates in WireCache) so that we could support external modules to handle cache storage. This capability is kind of similar to how we support 3rd party WireMail and WireSessionHandler modules. The first example is WireCacheDatabase, which is the default cache storage handler for the core. And today we have a new module called WireCacheFilesystem that replaces the default WireCache database storage with a file-system based storage, once installed. It's not yet clear if there are major benefits one way or the other (cache in database vs. file system), as I've not been able to put all this new code through performance testing yet. I'd definitely be interested to hear if anyone has a chance to test things out. I expect the file system might be faster for reading caches, while the database may be faster for writing caches. At least that's what I found with a few preliminary experiments, but they haven't been very thorough, so take that with a grain of salt. I thought we needed at least 2 examples of classes implementing WireCacheInterface before we'd be ready to support potential 3rd party WireCache modules. I imagine that 3rd party modules getting into dedicated cache options independent of database or file system is where we'll start to see major performance benefits. At least for sites that use the cache heavily. That's all for this week, have a great weekend!

Very cool! I just found this module and tried the demo. I am amazed how well it already works! Wow!! This could definitely be a game changer for some because it brings so much design flexibility to PW (of course the purists among us cringe inside 😅). I have been hoping for some solution like this and will definitely look into it more. Thank you for sharing!

Just a thought... One possibility is if you have Mod Security installed on the hosting. Often you will get a 403 (Forbidden) message on immediate posting if there's something in the page or posted content that triggers one of the modsec firewall rules. If this happens, nothing gets posted, and the 403 message is shown very quickly. I suspect the PHP Notice is probably unrelated.

This is true, with a couple of small twists: SearchEngine supports "pinning" specific template(s) to the top of the list, or alternatively grouping results by template. These require making slight modifications (adding extra rules) to the query (DatabaseQuerySelect object) generated by ProcessWire. In the dev branch of the module there is a work in progress "sort by relevance" feature, which also modifies the query. This is based on MySQL natural language full-text search, so it's still up to the database to decide how relevant each result really is. Sorting results by number of matches, giving some fields more "weight" than others, etc. are not currently something that this module does, though I have occasionally considered if they should be. The main issue here is that it would require different storage and search mechanisms, so it's a lot of work, and additionally it would raise a few rather complicated issues (e.g. handling permissions, which is something that we currently get "for free" by relying on selectors.) Not sure how sensible that would be, all things considered. It might make more sense to use SE to feed data to a separate search tool, or ditch SE altogether for that sort of use case 🙂

Just stumbled over this... https://www.slant.co/topics/5409/~php-cms

Hi @snck! Although teppo might have a different answer, I suspect it'll be similar to this. The SearchEngine module simply makes it dead simple to add standard search functionality into ProcessWire without handling it all manually yourself (i.e.: properly parsing/escaping fields, extrapolating searchable text from files [with the SearchEngine FileIndexer add-on module], and figuring out how to generate a search result list). Beyond that, it still uses ProcessWire's own search functionality; it doesn't expand upon it. ProcessWire can do some pretty significant things in search, but overall it still relies on MySQL's fulltext search to handle everything. MySQL can offer some level of relevancy (depending on the PW selector search you choose), but it can't, as far as I know, order by number of matches found. Relevancy is not (necessasrily/typically) the same as number of matches (per matched database record). For anything outside of MySQL's default capabilities, something external would likely need to be integrated, such as Apache Lucene or ElasticSearch.

Sorry to be so unclear! But this "we" referred to the PW project! 🤩 And yes, as @Jan Romero already said, it is only one in the wire directory, so that you can use your own in the site directories.

Sure, you need to understand at least the basics of CSS and SCSS before moving on to bootstrap or similar. To begin with, you might want to learn about how to shape page layouts with CSS as that is an essential part of website design.

Sad to see HTMX not listed as a front runner. HTMX all the way. It’s philosophy fits right in with ProcessWire.

Erm, bit late, but found it here: https://github.com/ryancramerdesign/SkyscrapersProfile

@wbmnfktr I'm not using @bernhard’s tool but you could go this way to have your initial migrate.php: $rm = $modules->get("RockMigrations"); $excludedFields = ["admin_theme", "pass", "permissions", "process", "roles"]; $fieldsCode = []; foreach($fields as $field) { if(in_array($field->name, $excludedFields)) continue; $fieldsCode[] = $rm->getCode($field); } $fieldsCode = "\$rm->migrate(\"fields\" => [\n" . implode(",\n", $fieldsCode) . "\n];"; $excludedTemplates = ["admin", "permission", "role", "user"]; $templatesCode = []; foreach($templates as $template) { if(in_array($template->name, $excludedTemplates)) continue; $templatesCode[] = $rm->getCode($template); } $templatesCode = "\$rm->migrate(\"templates\" => [\n" . implode(",\n", $templatesCode) . "\n];"; And export $fieldsCode and $templatesCode in a file. Regarding the verbosity, it unfortunately boils down to how PW generates the export data. You could be pretty agressive and skip all falsy values but you might get unexpected behaviour.