jbx

I had the same problem with the latest version 4.9.

In my case I was using the Disable REST API plugin to block all REST calls.

If you have the same setup you can fix it by:
1. Go to Settings -> Disable REST API
2. Click on the checkbox near /contact-form-7/v1 (at the top level), the four sub-levels should become checked automatically.
3. Click on Save Changes
4. Sign out

If you test it now it should work.

Thanks. For some reason some of the files were owned by a different user.
A chown solved the problem! I managed to update afterwards.

You shouldn’t really do that, because the moment there is an update the modifications you do in your PHP file will get overwitten.

You might want to look at how I did it, to avoid getting my translations working and not overwritten.

https://www.ads-software.com/support/topic/where-is-the-right-place-to-put-mo-and-po-files?replies=4

Not sure what exactly that solution is suggesting. What should I do use the old way instead of the new WP_Query? Other than that it doesn’t seem to do anything.

I don’t actually need to have that orderby with 2 fields, so I removed the second one, but still same effect. Infinity scroll just gets confused.

Could you explain a bit in detail what is infinity scroll doing and how it is working underneath the hood? Seems to be doing something weird with pagination, because suddenly I see /page/2 but its not clear what is actually happening, and there is nothing in the docs that explains this and how you should design your custom index pages to work well with it.

Yes. Its just that I want it to be configurable and making it configurable through my theme’s options makes functions.php the best place to have it.

Tried it out, seems to be working fine.

Thanks. I presume I can just paste that in my theme’s functions.php file instead of having another plugin? Its anyway specific to my site (the email is hardcoded) and I could actually get that from a field I make configurable in the Theme options.

Yes you are right. If I customise the subject myself it is then stored correctly. It is the default one that does not work properly.

I don’t know, maybe makes sense to actually save the default subject field on plugin installation, so that it is saved in the right way.

I will set this to resolved since for my case I managed to find a solution.

I am observing this too.
I entered a whole menu and the descriptions and prices for items which had descriptions went missing.

Items which only had prices went in fine (they kept the price).
Items with all details went in with name only.

I noticed sometimes the small ‘loading’ arrow on top takes a bit too long after pressing save. Might be related, I don’t know.

Hi,

Thanks for your reply. No I just started to use the plugin for a new website.
I actually got it to work well now by putting it in /wp-content/languages/plugins/ without the plugin name sub-directory. So its sorted.

Loco Translate gives you the option to create it in either the plugin’s language directory or the wp-content/languages/plugins/ directory which does the same thing. So I guess mystery solved. One shouldn’t put a sub-directory in the /languages/plugins folder.

Regarding the official language translation, I am not really doing a translation. I just wanted to replace some words like ‘Party’ with ‘Persons’ or ‘Group’, depending on the sentence, since they are not used in the same way colloquially here.

Thanks again.

Yes its really strange. I have full control over the server, its my own installation. If I do a wget on the index page of the server it works fine and downloads the page. I don’t know what difference there might be when running it via cron.

I guess an issue one might have with running php directly is the user under which it is run. Otherwise I don’t think there is any real difference in this case.

Mmm… now this is weird.

So I tried to add this to my crontab:

*/7 * * * * cd /var/www/html; php /var/www/html/wp-cron.php > /dev/null 2>&1

I still left the old one using wget. (Note that I had also tried to invoke wp-cron.php from my browser and also wget manually).

And suddenly all the messages were sent.

I can’t understand what’s the difference.

I read here that running php via the command line doesn’t have timeouts.

What could be the issue? Could it be I need to purge the database or something?

Hi,

Thanks for your reply.

Yes in wp-cron dashboard I see the first item.

Anytime after November 20, 2015 @4:02 pm execute tasks
Entry #1: newsletter √ action exists

(The time here now is 21:44).

I also turned on logs to DEBUG and the last message I saw was this:

20-11-2015 15:01:22 - DEBUG - 14.5 MB - hook_newsletter> Start
20-11-2015 15:01:23 - DEBUG - 14.1 MB - hook_newsletter> Emails found in sending status: 1
20-11-2015 15:01:23 - DEBUG - 14.1 MB - hook_newsletter> Sending email 135
20-11-2015 15:01:23 - DEBUG - 21.7 MB - limits_exceeded> Setting the limits for the first time
20-11-2015 15:01:23 - INFO  - 21.7 MB - limits_exceeded> Max time set to 285
20-11-2015 15:01:23 - DEBUG - 21.7 MB - limits_exceeded> Max number of emails can send: 833
20-11-2015 15:01:23 - INFO  - 21.6 MB - limits_exceeded> Max execution time limit reached
20-11-2015 15:01:23 - DEBUG - 14.1 MB - hook_newsletter> End

I thought that maybe W3TC was interfering with it in some way. But I deactivated it and the problem still persisted.

Trying to reactivate the Newsletter plugin now.

Well what they will do is click on the Members link, which if not logged in will display the login page (and then automatically it redirects them to the redirect url after they log in). The problem is if they go to the same page and they’re already logged in, they don’t go to the the Redirect URL but stay on that weird profile page.

If for example I have a ‘Members’ link on top, the user might click on that (maybe forgetting that he has already logged in, or maybe he had the ‘Remember Me’ turned on, or maybe just to go to the Members home page quickly).

I sort of got around it by putting a special page in my theme page-membership-login.php and added this to the top:

<?php if(SwpmMemberUtils::is_member_logged_in()) {
    $url = //my members url;
    wp_redirect($url);
    exit;
} ?>

Sort of a hack, because ideally its in just one place.

Cheers! Seems to be working perfectly now after the update.

No problem. If you choose the <-- mfunc --> approach you might face a few teething issues to get it to work, it has a few peculiarities, hopefully it doesn’t give you too many problems.