Leaderboard

Relative to ProcessWire 3.0.161, version 3.0.162 contains 24 commits that continue upgrades/improvements to selector operators, fix various minor issues, add new API convenience methods, improve documentation, optimize and refactor various portions of code and DB queries, and much more. For full details, see the dev branch commit log as well as last week’s post. Next week I hope to finally finish up a new version of ProCache and continue with some additional core to-do items. By early August my hope is that we’ll have the next master branch version ready. Also added this week is a new dedicated documentation page on this site that covers all of ProcessWire’s selector operators, including all the newly added ones here: selector operators. Thanks for reading and have a great weekend!

Using SSL should be quite straight forward, assuming that everything is configured correctly on the server side. The enforcing happens on the server the moment you issue an ALTER USER your-processwire-user@your-mysql-server REQUIRE SSL The moment you do that, you'll get a database error when you access your site. To enable PHP to talk over an encrypted MySQL connection, you now need to point it to the MySQL server's CA certificate. Copy that to a location where the web server can read it and add an entry in site/config.php (adapt the path to match your ca cert location): $config->dbOptions = array( \PDO::MYSQL_ATTR_SSL_CA => 'C:/temp/mysql-ca.pem' ); There may be scenarios where the name you use to access the server doesn't match the name in the certificate and you get the error "SQLSTATE[HY000] [2002]". The same error occurs when you use a self-signed certificate in the server (that's the case when you leave things to default after installing MySQL on most distributions). In that case, you need at least one of the following PHP versions: PHP 7.2, 7.3, 7.4 or 8 all versions PHP 7.1 >= 7.1.4 PHP 7.0 >= 7.0.18 The reason is that earlier versions of the MySQL PDO module didn't have the flag to disable certificate verification. You need to expand your entry in site/config.php: $config->dbOptions = array( \PDO::MYSQL_ATTR_SSL_CA => 'C:/temp/mysql-ca.pem', \PDO::MYSQL_ATTR_SSL_VERIFY_SERVER_CERT => false ); Most (hopefully all) PW modules should be using the PDO interface by now, but you may stumble upon one that still makes use of the old mysqli wrapper. Those won't work with an SSL connection.

Good article and postgresql looks interesting with its search capabilities, thanks. Though none of these really solve what I was after here. I experimented quite as bit with stemming and different stemming libraries. Though they all did roughly the same thing. When it came to searching, stemming just wasn’t that useful. WireWordTools originally had a stemming library and methods, and the appropriate fulltext queries included the word stems with wildcards. In the end, it just wasn’t helpful most of the time. And in the few cases where it was worthwhile, it was redundant, though far less thorough, than what we already had with inflection and lemmatisation. So while stemming can have its uses, it’s not even half way there, if trying to build a smart search. Cool nevertheless that they have it built-in apparently. As far as accent support, ranking and fuzzy search, these are all things that MySQL does as well, though maybe there are differences in how they do them. For instance, MySQL supports “sounds like” and also supports pluggable parsers for fulltext searches. Fuzzy search also isn't what I'm after here, but certainly interested in exploring in the future. For me the most useful thing by far is boolean mode searches, particularly in InnoDB, which has a full-text engine modeled on Sphinx. Boolean mode searches are really very powerful, enabling you to specify what’s required, what’s excluded, matching of words or phrases, partial matching of words with wildcards, specifying noise words, isolating distance between words, adjusting ranking up or down on a per-word basis, grouped expressions and nested subexpressions. All while being incredibly fast. I’m pretty thrilled with what MySQL supports here and what it brings to ProcessWire. Postgresql looks very nice too, but for our needs, I don’t feel we are lacking anything relative to it. I think anyone that would say that as a general thing is not very familiar with what MySQL fulltext supports, or maybe is thinking of fulltext support where it was back a long time ago. For ProcessWire and the scale that most use it at, MySQL fulltext is really a sweet spot, enabling PW to deliver enormous power and capability when it comes to search features.

You're right, thanks for letting me know. Links should be fixed now. I just switched to a different GitHub username and hadn't come around to updating the links yet. The docs can be found here now: daun.github.io/processwire-dashboard/

I'm using SessionHandlerDB: $s = $modules->get('SessionHandlerDB'); foreach($s->getSessions() as $session) { $s->destroy($session['id']); } If not using SessionHandlerDB it should be enough to clear /site/assets/sessions

Hello @ all Today I want to share an inputfield/fieldtype to store 2 or 3 dimensions of an object. This fieldtype was inspired by the amazing fieldtype "Fieldtype Dimensions" from SOMA. This fieldtype was introduced in 2013 - so its time for a relaunch. This new fieldtype offers more possibilities than the old one. This inputfield/fieldtype let you enter max. 3 dimensions (width/height/depth) of an object (fe a product), but you can select if you want to display inputs for 2 or 3 dimensions. 2 dimension can be used fe for wallpapers or photos, 3 dimensions fe for furnitures or other objects. There are several configuration options for this fieldtype in the backend. set type (2 or 3 dimensional) set size unit as suffix after each inputfield (default is cm) set max number of decimals (default is 2) show/hide a hint to the user how much decimals are allowed If the number of decimals will be changed, the database schema for each dimension column will also change after saving the field in the backend. For example: If the schema for each dimension field in the DB is f.e. decimal(65,2) and you will set the number of decimals in the configuration to 3, then the schema in the DB will also change to decimal(65,3) after saving the inputfield. You can download this inputfield at https://github.com/juergenweb/FieldtypeObjectDimensions There you will find more detailed information and explanation too. If you find any bugs or you have an idea to improve it (also code improvements) please report it on Github. Have a nice day! UPDATE 14.06.23 / VERSION 1.2.2 I have re-written the complete fieldtype to be compatible with PHP 8.2 and refactored some of the methods and the database scheme. If you have downloaded the fieldtype before, please deinstall the old one and make a new install. I have added this fieldtype to the Processwire module directory. After it has been published, please download it from there.

thanks! I figured out my own approach, works as well… $cols = $page->table->getColumns(); foreach($cols[10]['options'] as $opts => $value) { $out .= '<option value="'.$value.'">'.$value.'</option>'; }

The API for this is kinda ugly but it works. Where "3" is the number (in order) of the subfield / column you are looking for.

I mean, you could do something like this: //in site/ready.php $this->addHook("Page::renderBlock", function($event) { $page = $event->object; if ($page->template->altFilename) $blockPath = $page->template->altFilename; else $blockPath = $page->template->name; $blockPath = "blocks/{$blockPath}.{$this->wire('config')->templateExtension}"; $event->return = $page->render($blockPath, $event->arguments(0)); }); Now you can call $page->renderBlock() or $page->renderBlock(['this' => 'that']) and the block’s template path will be determined automatically according to the template settings. Or this, maybe: $this->addHook("Page::renderBlock", function($event) { $page = $event->object; $templatePath = $this->wire('config')->paths->templates; $templatePath = substr_replace($page->template->filename, 'blocks/', strlen($templatePath), 0); $event->return = $page->render($templatePath, $event->arguments(0)); });

It works now. Thanx for fast solution!

Unfortunately not. The mysqli wrapper uses the object oriented interface, so there isn't even an easy point to add that part in the core library between instantiating the module and invoking mysqli_real_connect(). Your best bet is to look at the stack trace to see which module causes the dump (enable $config->debug in site/config.php) and either find a replacement or post an issue in the module's git repo to get it converted to PDO.

@jploch Does this help? On the Template -> Edit -> Files tab, you could nominate an alternative template/path for your PageTable template.

Another approach to try: // Store page changes in custom property on $wire $wire->addHookAfter('Page(template=contact|sample)::changed', function(HookEvent $event) { $page = $event->object; $what = $event->arguments(0); $old = $event->arguments(1); $new = $event->arguments(2); $page_changes = $event->wire('page_changes') ?: []; $page_changes[$page->id][$what] = [ 'old' => $old, 'new' => $new, ]; $event->wire('page_changes', $page_changes); }); // Send email if there are page changes after the request is finished $wire->addHookAfter('ProcessWire::finished', function(HookEvent $event) { $page_changes = $event->wire('page_changes'); if($page_changes) { // Send the email using the values in $page_changes ... } });

Hi @kongondo, thanks for referencing this newer topic. Connection problems can be solved, but these are only the tip of the iceberg, I fear. I gave up a bigger PW project because of the performance problems we got with MySQL 8. The main reason for these problems seems to be the MySQL Server Team's decision to remove support for the query cache in MySQL 8. To quote Matt Lord: "MySQL 8.0 will not support query cache, and users upgrading will be encouraged to use either Server-side Query Rewrite or ProxySQL as a man-in-the-middle cache." (https://mysqlserverteam.com/mysql-8-0-retiring-support-for-the-query-cache/) The vast majority of the PW users will not be able to use such configurations, with server-side Query Rewrite or ProxySQL, and i doubt that such a configuration could be an equivalent replacement in any case, but I hadn't an opportunity to test it.

This is where postgresql outshines mysql by far. It can do stemming and accent support for multiple languages out of the box, ranking, fuzzy search, … which are the things you found missing. Many people/resources seem to suggest not bothering with mysql for advanced full text search needs, but directly going to purpose built external technologies for that, while postgresql provides a stepping stone, before needing to go that route.

Try calling wire('pages') instead of $pages.

@bernhard I didn't come up with the dictionary words in the JSON files, they are converted from an existing one (here) and apparently the original source is wordnet.princeton.edu. So I'm not sure if those particular words are intended or mistakes. New to me, but "wa" and "wo" are actual English words. Though as far as I can tell they aren't related to "was" or "will". I can't imagine those two instances will ever be helpful for our intended use case so maybe it makes sense to remove them. My plan was to keep looking for more existing dictionaries and continue to merge them into the one in WireWordTools so that it becomes more comprehensive over time.

Hello @ all! I want to share a simple fieldtype and inputfield to store address data with you. I have created this inputfield for learning purposes and it has no fancy functionality. It is simply for storing address data such as street, number, postalcode and so on in one table. As an addition you can store latitude and longitude too, so you can use them in maps. Here is a screenshot of what it looks like: You can select which fields are mandatory and you can choose if the inputs for longitude and latitude should be displayed. These settings can be configured in the field configuration. If you find this inputfield useful you can download it at https://github.com/juergenweb/FieldtypeSimpleAddress There you will find a detailed explanation. If you have an idea of an usefull feature that can be added or you have detected a bug, please report it in my github account.

In case you missed it, GitHub bought npm https://blog.npmjs.org/post/612764866888007680/next-phase-montage https://github.blog/2020-03-16-npm-is-joining-github/

So let's call it a scam as we should not call it web development. Playing dirty tricks is one thing and being honest and helpful is another one. I always stick to the latter. Sure, I will never become a billionaire with my "silly" attitude but at least no hordes of angry people are chasing me my whole life. Instead, I have a bunch of friends who know they can trust me.

Sorry for not finding this discussion earlier. It sounds like the issue is already resolved, but I'll just add a couple minor points. Multi-language support is something that is installed by modules rather than something that's in the core from the beginning. As a result, the "default" language is the one you would have if you had no multi-language support installed. Likewise, the content of the default language is the content that would remain if you later uninstalled language support. So you need to think of that default language as the foundation or core language of the site. Once you start using multi-language fields, you can't easily swap in another language as the default (at least not without copying/pasting or making a little scripts to move things for you). If you needed the ability to do that, then you'd probably want to consider your 'default' language as unused on the front-end, and delegate all of your languages to non-default languages. I think it would be perfectly fine to consider the "default" language as "no language". When editing a page, you'd still be left with placeholders for the default language, which you'd probably just consider to be notes for the admin. The default language homepage is always represented by the root URL, "/", regardless of what name you've given it in the homepage settings tab. This is to ensure that a user arriving at your homepage doesn't encounter an immediate redirect to /en/ or /de/ or the like. Redirect from homepage is a behavior frowned upon by search engines, and generally considered a bad practice regardless. So ProcessWire is coded to prevent an automatic redirect from occurring on the homepage. That default language name comes into play on the rest of the pages in your site. If you wanted your homepage to be nothing but a language gateway (with no default assumed) then you'd need to delegate your real default language homepage to a separate page, like /en/welcome/ or something like that, which your language switcher can link to.