Caleb

Changing collation only on post_title is OK, and looking at your site it probably fixes 99.9% of your issues. Doing only one field, and not the whole table probably also saves you some of all the heart-aches I mentioned above. 🙂

However, if you in the future have other pods or post items such as post/pods Categories, Taxonomies, or tags where there could be Danish characters, then they will of course not be fixed by this. You would either have to fix those individually or make a more global change.

At least you avoided having to add my goofy, global filter code. 🙂

Hvor rejser man til? Der er mange muligheder. 🙂
Jeg rejser typisk rundt i USA hele aaaret for at fange de mest behagelige temperaturer og besoege sceniske steder. Til toppen af bjerge i Colorado, besoege Glacier National Park i Montana, Yellowstone, run the Pacific coast US-1… Hvad jeg nu har lyst til det aar.

Lige nu har jeg “siddet stille” en god tid i staten New Mexico. Omkring 30 miles fra graensen til (originale) Mexico.

OK.. Assuming that you do not want the BIG conversion project, I just tried to switch my test environment to Danish and create some test Danish posts and pods. Some Æggebakker posts and such. 🙂

Of course WordPress failed miserably in sorting these. 🙂

So, since default MySQL/WordPress is doing it wrong, I did this to teach the pair to sort.

MySql can be told to use a collation different from it’s DB/table configuration on individual SELECT statements. By using the COLLATE clause.

Since WordPress unfortunately does not do this, even after a correctly set DB_COLLATE in your wp-config, you can add the below code to your theme’s functions.php (I am hoping you are using a child-theme as one should always do?? 🙂 )

First set DB_COLLATE in your wp-config to ‘utf8mb4_danish_ci’.

then add the below to the theme functions.php

function fix_Collation($query) {
    if (defined('DB_COLLATE')) {
	$col = DB_COLLATE;
	if ( preg_match( '/^\s*(select).+(ASC|DESC)\s/i', $query ) ) {
	    $query = str_ireplace(['ASC', 'DESC'], ['COLLATE ' . $col . ' ASC','COLLATE ' . $col . ' DESC'], $query);
	} 
    }
    return $query;
}

What the filter does is catch all the DB queries going through the system, and when it sees a SELECT … ORDER BY type statement, it adds a Danish collation to it before it can be handed to MySQL for execution.

That fixed my WordPress to act very nice when you speak Danish to it. 🙂
Sorting by title in various places such as ‘Alle Indlæg’ now knows where to put all my Æggebakker and Øldåser. 🙂

NOTICE, my database character set and collation is utf8mb4 .
If your database is running the older WordPress setup with ‘utf8’ characterset, you will need to replace the utf8mb4_danish_ci in the above with ‘utf8_danish_ci’.
utf8 and utf8mb4_danish_ci do NOT work together.

It is a little simplistic, since I only had a few minutes, but it works without fail in my test. There is no guarantee, though, that some plugin or setup could not generate a SELECT syntax where my simple replacement logic could create invalid SELECT syntax by sticking the COLLATE in some places mySQL don’t want it. 🙂
Just keep that in mind if you ever start seeing SELECT syntax errors in the future, and do some fixing. 🙂

But.. Try it out and see if it takes care of your issue. If so, it is a 1 minute fix.

On your first response, the pods direct example.

Pods simply transfer this into a MySQL query. Your ‘orderby’ spec translates into an ‘ORDER BY’ clause on the SELECT statement sent to MySQL. No further sorting is done by pods or even WordPress itself.
So, for that (and many other things) to work, your MySQL tables have to be set up to sort correctly in Danish. The Character set and collation method have to have been set correctly.

That same thing goes for your second response. Sorting by ‘post_title’ will only work if the system is setup correctly. Preferably from the very beginning, before you start adding data.

Selecting “Danish” as the WordPress language unfortunately simply makes WordPress pick a specific set of language translation files. Suddenly renaming “Web Site” to “Websted”, “Papirkurv” instead of “Trash” and similar. It makes WordPress speak Danish. BUT.. It does not magically change your databases, the characterset it uses, or the collation method. Those are set deeper, and again, the defaults to use when creating tables should have been chosen BEFORE actually creating tables.

The default MySQL characterset and collation is defined when MySQL is installed. Set in it’s configuration. But those MySQL defaults are only used, when the creator of the table (here WordPress) do not specify something on their own when they issue the CREATE TABLE.

If you look at your post table in MySQL/phpMyAdmin, you might see that the table has been created using something like characterset ‘utf8’ or if starting on later versions of WordPress ‘utf8mb4’, collation “utf8_general_ci”.
utf8_general_ci as a collation will not sort Danish or any other language with special characters correctly. The collation would be something like ‘utf8_danish_ci” to come out from MySQL correctly.

In your wp-config.php file, you would see lines like these (these are the defaults):

define(‘DB_CHARSET’, ‘utf8’); // (Or utf8mb4)
define(‘DB_COLLATE’, ”);

They are used on table creation (during WP install) to define the correct table characterset AND Collation.
They SHOULD have been defined as I described above (with a Danish collation) to get a correct result.

In your case, your tables already exist, have already been set up. So, they are likely not speaking or collating correct Danish. 🙂 Only way to get MySQL to change is to change/convert the tables using ALTER TABLE.. Mind you, this will most likely be a hassle, because ALTER TABLE refuses to change the collation with incorrect data in the table (even for irrelevant stuff such as date default formats).. So ALTER TABLE at times flunks out repeatedly complaining about validations failing, because of goofy stuff WordPress has stuck into the tables.. Like using now invalid defaults on date fields, and using zero value dates on WordPress (auto-)drafts, …
So the path to completing the ALTER TABLE for collation can be a long one, where you first must fix the bad data and table field defaults, before the collation change can finally happen.

You could be in for somewhat of a project. Either for you of someone with more experience. This is not something that can be handled through a Pods support group, since it is very local, very MySQL, and very WordPress installation specific. Not really Pods at all.

The best would of course have been if all this was setup correctly and collations tested to work on initial install.. It it is much harder to fix after the fact, when the data and config is already present and have to be “fixed”.

Notice, though, that you have other measures that can fix sorting on pages.
There are many ways to skin a cat.

One is to simply ignore the MySQL sorting and doing it “yourself” in the code.
For example, my short-term (or maybe even permanent) fix for this would have been to add a routine that could correctly sort data using the PHP Collation class, and then simply sort it on the way out. Run the Pods select, get the data without caring about how it is sorted, and then “Danish sort” it in PHP before outputting the page code. In effect hiding the fact that the DB actually returns things out of order, when viewed from a Danish perspective.

Mind you, that means you cannot use Pods Templating or Pods Short-codes in pages of course. You would have to put a little more work into it. 🙂
My opinion stems from me not using Pods Templates and short-codes at all. I use Pods code/MySQL, and WordPress templating all the way.

Hvordan er vejret i lille Danmark for tiden? Stadig sommer eller er efteraaret paa vej?
Hvor jeg er lige nu er efteraaret ved at anmelde sig. Eftermiddags temperaturer begynder at droppe under 35 grader.

In a normal WordPress environment with “normal” plugins. No it runs fine.
Some plugins might produce errors under things like E_STRICT because they have not tested PHP7 but it still runs. Haven’t seen anything fail yet.

PHP5 is seriously old at this time anyway, so developing with PHP7 is the right thing to do.

I have no real live sites running less than 7.1 at this time.. WordPress runs just fine on it.

I think @topsan123’s problem might be a little different, since running a WAMP setup.
I use a local Development setup with WAMP for some things as well Of course WordFence is completely meaningless to that development environment and need not actually run.

But for testing purposes I tried it anyway, and this is what I see:

During WordFence activation, it runs through a lot of stuff, including parsing the rules file.

There is an odd (and unexpected) incompatibility between what WordFence does during wfWAFRuleParser::parse() and the typical (or some) WAMP setups..

So while parsing, it suddenly and silently crashes. (Crashes the running process.)
No visible errors anywhere, other than the apache-log shows an MPM client died and it being restarted.

Instead of the plugin getting enabled, you get the standard Chrome/Windows “cannot be reached message), because for a while the Apache server/PHP is not responding to the redirected connection.

If the WAMP setup is done correctly, the service restarts automatically, and a second later the test site serving is normal (you are still on the “cannot connect message, though).
But it is normal in the sense that all you (or I in my case) have to do is press the browser Back button to get back to the plugins list.. With the Apache process automatically restarted, everything is normal again.
No need to go remove it in the plugin folder, because it never got activated.

The only thing I cannot do is enable WordFence. The parser will consistently crash the system during the activation process every time, and so the plugin never get’s activated.

I never took the full trouble to figure out why the parser is so tricky for Apache/PHP, since I certainly don’t need WordFence on a “loopBack” connected development environment with no access other than me. I only installed it for potential plugin compatibility testing purposes.:-)

Yes, turning off all user (and site) registration is already a standard WordPress feature. Have been for many years. At least in multi-site installations.
An option under “Network Admin” => “Settings”.

Not sure whether in single site installations that option moves into that single site’s Settings or not. I would never put up a single-site install. i never even tried it. 🙂

However, that does NOT disable creating individual users as an admin from the admin screens. One can still create new users, both SuperAdmins and individual site users. It is just that no one can “register” an account, since they MUST be created by an admin (or a plugin).

So even with that option turned on, that does NOT prevent goolish plugins wanting to create users, similar to Woocommerce. Pretty much all commerce, forum (such as bbpress), and similar plugins would frequently still create users as usual, since they typically bypass the WP registration process similar to how WooCommerce does it. Creating users into the user-tables using WP functions.

BUT… By filtering on ‘illegal_user_logins’, that would block all banned user names through all the normal WordPress user paths used by plugins. No one can then register any names, unless an existing Admin user or a plugin does it for them. And even for Admins creating any “bad” names are blocked, since edit_user is blocked.

The only way remaining for hackers would be to get DB access (to DB directly or through an unsafe WP plugin) and then simply stuff the user-tables manually, without bothering to go through the WP functions.

Personally, I don’t worry too much about such things anymore (right now at least).
My sites are so relatively hard that no one can get too close to my back-end functions (including wp-login or xmlrpc). If they are not in the right world-area (i.e. are near me) they are met with an error 418 (“I am a little TeaPot”) just to poke fun at them. 🙂
Many, many times a day do we throw the TeaPot at the whole world’s IPs. 🙂

Not even comment spammers get through.. Akismet is mostly on year-round vacation, yet it’s stats proudly announce that Akismet have seen the enormous count of 24 spams over the past 12 months). That’s somewhat like when a 5-year old proudly announces that they are tying their own shoe laces. 🙂