ak

Could you reproduce this?

Funnily enough as I now tried to reproduce the bug so that I could debug it with the Network tab it was working alright. I did double check (and actually checked once more just 10 mins ago), but now it is gone. I don’t think I did anything differently. I also did wait for a quite a bit of time for the AJAX to load before concluding that it was not loading…

I did remove some events from the trash and did save again the Event Organizer settings. Quite far fetched, but anyhow the problem seems to be gone. It would still be a nice feature to see a notice or have an auto addition to save the clients from the confusion.

Thank you really much for you quick answers!

Hi,

sorry I mistyped. I meant the venue search field in the add/edit Event page has jammed (it does not reach to typing nor does the “Show All items” arrow work.

Yes, I instructed the client to use the search in the future, but the user might not always remember that the venue has already been added.

I would prefer both: Automatically assign to the previously given venue and give a message that the venue already existed.

I do not see any errors in the JS console of Chrome.

I managed to solve this!

The problem is with postie-functions.php line 1090
$meta_return .= htmlentities($part->body);

Which should be
$meta_return .= htmlentities($part->body, ENT_QUOTES, “UTF-8”);

Because default encoding parameter for htmlentities was changed to UTF-8 in PHP 5.4.0 so it fails with older versions (if I’m right it does an UTF-8 to ISO-8859-1 conversion here, which causes the problems).

I can confirm this bug also, Finnish characters ??? cut the message, or they are interpreted in a wrong manner (? > ā or something). Reminds me of problems when opening ISO-8859-1 encoded files with UTF-8 editor.

However, I did not have this problem before I updated couple of days ago from an older version, just can’t remember what is was. I have a backup for the database, where can I find the older version number?

Hide backend multisite support.

In practice this means means that the request to example.com/subsite/administration-slug, subsite.example.com/administration-slug, or (domain mapped) examplesubsite.com/administration-slug, should be redirected to example.com/subsite/wp-login.php, subsite.example.com/wp-login.php, or examplesubsite.com/wp-login.php, rather than to example.com/wp-login.php, where they are now being redirected to.

Hi,

i am experiencing the same problem.

Handoko, the case is not just as you describe. Many use multisite installations with e.g. multiple different domains, where the subsites have been domain mapped to a different domain than the mainsite. In these cases, the users use the examplesubsite.com/wp-login.php to login. Often, they might not even know, that their website is running on a multisite installation and that’s why logging through the mainsite is not an option.

Even with just one domain, users often use the example.com/subsite/wp-login.php (or subsite.example.com/wp-login.php) to login.

So in order to work correctly, the hide backend url rewrite should direct the example.com/subsite/administartion-slug to example.com/subsite/wp-login.php, not to the main site login.