Leaderboard

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.

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.

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 ... } });

Cross referencing a similar topic with, possibly, an answer to your question @Lutz

Since your Page::changed hook is called, trackChanges already appears to be enabled. Have you tried getChanges(true) inside a saveReady hook? Also, the change information should be visible in arguments 1 and 2 in a Pages::saved hook.

I can replicate here. There must be something wrong with the image, as it opens in FF and other deskop image viewers on windows. I recreated webp from your original jpg (using online jpg to webp converter) and this time Chronme shows the image. I have no idea what could be wrong, possible Chrome issue?

@LostKobrakai thanks for the explanation! very helpful. Actually I created a second datetime field now, where I store the walltime of the user when the post is created. I just use this field then to display the time on frontend, instead of created. Messing with the actual created date could really make problems - thanks for the insights - especially because you still want to keep the real "order" (dependend on UTC or a universal time) of posts, even tho individual local time is different.

Updated to 1.0.1 (Stable), mainly reducing hook priority < 200 so it runs before ProCache.

If you're dealing with multiple timezones I'd strongly suggest not involving the db in it. There are two types of datetimes: absolute time (times you want to compare with each other even across timezones) and wall time (11 o'clock stays 11 o'clock for your user). Because timezone defintions can potentially change for future datetimes it's not always as easy to keep both properties as one might think. If only the first one is important to you you should keep everything in UTC. If only the last one is important you could use a datetime in the timezone of the user, but it's rarely the case you don't compare timestamps or it doesn't become a requirement (e.g. for ordering). For past datetimes it's enough to store a utc timestamp and the timezone of the user to get to both the absolute time and the wall time as timezone defintions rarely change in retrospect. For future datetimes you'd need to make sure to save enough information so you can detect changes in the timezone definition when they happen. Then you or your user can decide if absolute time or wall time was meant to be consistent.

@gmclelland UI Blocks is a front-end output strategy that we built at Solution Innovators. Not in the module directory yet due to a lack of good documentation. But I'm getting close to having that ready ?

Hey @Wanze What a great module! Thank you very much - I love the flexibility. One update I would like is the ability to use the meta image field as an actual image field, it would be much more understandable for clients rather than trying to find the image URL.

It's not only the same error in the log, but you're also doing the same thing wrong. You can't use $pages in functions because of variable scope. ProcessWire makes these object automatically available for the scope of the templatefiles, but inside a function is a new scope, so you need to either redefine the variable itself or use a function to get the object. // Template scope $id = 15; // simple variable, defined by you $pages = $pages; // the pages object, defined automatically by processwire function something(){ // this is now a new variable scope // neither $pages nor $id are available here. // the api variables are not a special global variable $pages = wire('pages'); $pages->find(""); // OR just wire('pages')->find(""); } It's the same reason, why you can't use $pages in modules. $page/$pages and the other variables are just convenient to use in templates. Everywhere else you need to call them differently.