Lutz

@matjazp No, eventually not new in the case I mentioned, that installation is on 3.0.165. But jom pointed to 3.0.210, so I don't know. However, this bug seems to be a bit obscure, since I couldn't found something special with the templates that didn't appear in the pulldown for changing templates. Every related configuration was double checked, and I also couldn't found something special in the database records of these templates. But when I was looking for a simple reason, before I found this thread, it becomes clear that this is not a problem regarding every page and every template, there were cases where it was possible to change the template. And it becomes even more interesting when I discovered that there was one template I always could change to--but couldn't found anything different in the relevant configuration of this template. The next step was that I added a new template, just to test this out. And with this new template I couldn't replicate the error. So now I deleted a template I never could changed to and added it a second time. And the problem seems to be gone. Of course, there must be a reason for that, but I can't find what is going on, and I have no idea why it seems to work now, while we are still on 3.0.165 there, so without the fix you mentioned. BTW, thanks a lot for the link to this commit. Update: I applied the fix for #1363, this seems to solve the issue. Thanks again, @matjazp!

Wow, in 3.0.210! Just was stopped by this error. Does anyone know if this bug has been fixed in Dev? I checked to see if I could find this in the issue tracker, but I couldn't. Maybe I used the wrong search terms. A downgrade to 7.4 is not an option, for security reasons.

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.

Tested with ProcessWire 3.0.149, no errors so far. However, it's terrible slow, especially admin, worst when using ListerPro. For example, there's a page with 5 children, the lister shows 5 results, execution time > 5,000 ms. If you open the config of that lister, execution time is > 8,900 ms. Go to Pages (pages tree), execution time > 2,000 ms (for just a few test pages). Cluster insights shows load average 1-minute peaks above 3 (1 vCPU cluster), for just one user, a few clicks. 5-minute peaks are around 0.9. CPU usage is ok./low (~ 7.5 %), memory usage ~ 80 % (1 GB RAM). Of course, this combination (PW + DO database cluster 1 vCPU/1 GB RAM) cannot be used at the moment. I try to continue researching.

Thanks @dragan and @elabx. I fixed the timeout error while testing with a non-PW script, will begin testing with ProcessWire soon.

@flydev ?? Thank you very much. Of course, host an port number are different, but the settings are triple checked.

I'm testing DigitalOcean's database cluster service, MySQL server version is 8.0.17. The tables were migrated from a MySQL 5.7 database, the database user is altered to support mysql_native_password (instead of caching_sha2_password). In config.php, $config->dbOptions is set to an array with \PDO::MYSQL_ATTR_SSL_CA => '/path/to/ca-certificate.crt'. I get the following error message when I try to access the website: Error: Exception: SQLSTATE[HY000] [2002] Connection timed out (in /path/to/wire/core/ProcessWire.php line 460). Does somebody use ProcessWire with such a configuration (MySQL 8, SSL) or has any idea how the problem could be solved?

@Knubbi The number of active connections refers to the server, not the individual database. Call the tech support and say that you need a written answer. I don't think that the issue originated from your switch to ProcessWire, but from switching to MySQL 5.7. As I said, if you are using MyISAM, it should be safe to migrate to MySQL 5.5 for a quick fix. You told us that there are no user accounts despite that of the admin, therefore it can be assumed that there's a lot more read access than write access. If so, I don't think that you would have performance issues with MySQL 5.5. Under such conditions there's little benefit through using InnoDB. Edit: Sorry, I had a second look on your first posting, I think I mixed up different things here... I had an issue with the number of concurrent connections on overloades Ionos MySQL 5.7 servers, but maybe in your case there's another error involved. Is your php error log activated and is there any other error logged? Do you have Tracy installed and can you check your code with debug mode on?

Sorry, I don't agree. In particular, I'm not happy about the direction this thread is taking. A ProcessWire user needed help, I tried to give a hint regarding a quick fix and some information about special difficulties with the new Ionos MySQL 5.7 servers. Was it helpful? I don't know. However, is it helpful to denigrate one of the biggest hosting companies in Europe, with just those facile arguments? whtop e.g. shows some anonymous critics of Ionos in the US, not Germany/Europe, and I must say I'm not impressed at all. To be clear, I'm frustrated about some problems I have with Ionos myself, but I think we should try to speak exactly about what's going wrong, about errors and their reasons, and how we could fix them, if it's possible. What I mean is, I don't like those complaints like Ionos is the worst hosting company ever or WordPress is hell on earth. Knubbi has problems with a MySQL 5.7 server, which he uses as part of a managed server account. Such accounts gives you access to a fast, dedicated server, but without root access. You can use them like you would use a shared hosting account, but without sharing recources with other clients, there's just one account on one machine. If you use a MySQL 5.5 database, this also is true regarding the databases, the MySQL host is localhost and those database servers rarely have problems. However, Ionos was very late with offering MySQL 5.7 servers for those hosting accounts, and because of the side effects a complete migration of all databases to MySQL 5.7 would have, they decided to leave existing databases untouched, to offer still the creation of new MySQL 5.5 databases and to give their hosting account clients just an option to create MySQL 5.7 databases, if they needed them. And these MySQL 5.7 databases are, unlike the 5.5 ones, centrally managed, on other hosts. So, I agree that this is a problematic decision, with regard to that it's no longer completely true to claim the resources of those accounts dedicated, but I think you can understand the reasons behind this decision, and they give you a warning about this fact before you can create a MySQL 5.7 database (instead of a MySQL 5.5 one). The real problem here is that they haven't made it so far to achieve a stability of those MySQL 5.7 servers that would be comparable to that of the 5.5 ones. I try to address this problem to this company, because I think it would be helpful for many customers like Knubbi when they find a working solution, and for some of my own customers as well. Would he be better off using another hosting company? Well, perhaps. But I don't think this is as clear as ist seems, neither regarding every hosting client of Ionos in general nor regarding users of those managed server accounts in particular. Ionos isn't one of those little companies with just a small data center or some borrowed rack space, they have a big, well-developed infrastructure, and one of the advantages of using those managed hosting accounts is to get a reliable DDoS protection for free. Maybe you never need something like this, but I can tell you that there can be very good reasons to choose such a managed server account. Whenever you were under fire with a mission-critical website you are responsible for, you know what I mean. Don't compare those accounts with shared hosting accounts. If he had well thought out reasons to use a Ionos managed server, he probably has to think about using a dedicated server or a cloud server instead. If his Internet presence requires mission-critical uptime, this means that he has to be experienced enough (and has to have enough time!) to make all the server admin work himself, or to hire two and a half DevOps to manage the servers. Or, of course, he has to find a more reliable and big enough hosting company with managed server accounts and without the problems Ionos obviously have. @Knubbi Well, if you will find such a company with comporable services, including some scalability and DDoS protection, please let me know. ?

@wbmnfktr These are server stats, not just stats for the database in question. Ionos uses their MySQL 5.7 servers for many different databases in parallel. ?

6 k failed attempts to connect to the MySQL server – this looks like stats of a MySQL 5.7 server, I know those numbers very well, and I think Ionos has a problem with their server configuration or with their entire MySQL 5.7 server concept. I checked stats of Ionos MySQL 5.5 servers we use, for ProcessWire as well, 0 failed attempts. Maybe you should try to use MySQL 5.5 there, to get a fast workaround, but I think you also should inform the server support, because of course you should be able to use MySQL 5.7. And yes, it's good to know that I'm not the only one who has serious problems with their MySQL 5.7 servers, and that I'm not the only one who addresses this.

@Knubbi Is it a MySQL 5.5 or a 5.7 database? If you are using MySQL 5.7, you could try to migrate the tables to another MySQL 5.7 database. (If you create a new database, chances seems to be high there that it's created on another database server.) We also have problems with those errors, which, however, are not (or not only) caused by ProcessWire. (I've seen such errors in an Dev environment when we had just two users online... Have a look at some MySQL server stats, you very likely will find some signs of a heavily overloaded server. Contrary to their information about dedicated ressources regarding managed servers, Ionos (1&1) uses MySQL 5.7 database servers for several accounts in parallel, not just one for your managed server account.) If you are still using MyISAM, it also should be save to migrate to an MySQL 5.5 database instead. Whenever I compared server statistics, MySQL 5.5 servers at Ionos (1&1) had less problems than their MySQL 5.7 servers.

Not tested, but if you use Apache 2.4 it should work something like this: # Define Directives: # AuthName # AuthType # AuthUserFile # AuthGroupFile # If Request_URI == your_admin_url: set environment variable authb SetEnvIf Request_URI your_admin_url authb <RequireAny> Require not env authb Require valid-user </RequireAny>

There's another thread regarding this issue, As a fast workaround you could try to use $sanitizer->textarea() instead, https://processwire.com/api/ref/sanitizer/textarea/ (maxLength to 200, stripTags defaults to true). Or use this simple function:

@Wanze Hm, I wouldn't like to see german umlauts encoded and it shouldn't be necessary, if we use UTF-8. In many cases it should be sufficient to use htmlspecialchars with ENT_QUOTES here. If you see a need to use htmlentities instead, you could flag with ENT_XML1, to avoid encoding äöüß.