Forum Replies Created

Viewing 15 replies - 16 through 30 (of 79 total)
  • Thread Starter ymf

    (@ymf)

    Actually, @slaffik, I have a different question: wasn’t this plugin supposed to fill the missing “FROM” header with blog owner-set default?

    In the WP Mail SMTP’s admin area I have the following setups:

    From Email: [email protected] <– “The email address which emails are sent from. … Please note that other plugins can change this, to prevent this use the setting below.
    Force From Email: Not checked <- “If checked, the From Email setting above will be used for all emails, ignoring values set by other plugins.

    From Name: My Blog Name <– “The name which emails are sent from.
    Force From Name: Not checked <- “If checked, the From Name setting above will be used for all emails, ignoring values set by other plugins.

    So I thought, if UpdraftPlus attempts to send an email with a missing From Email field, the WP Mail SMTP would use my above-set default “[email protected]”. Likewise, if UpdraftPlus attempts to send an email with a missing From Name field, the WP Mail SMTP would use my above-set default “My Blog Name”. That’s what I assumed. Apparently, this doesn’t happen: the WP Mail SMTP produces an error message and doesn’t send the email at all.

    Can you look into this again?

    Thank you!

    Thread Starter ymf

    (@ymf)

    I installed “WP Mail Logging” plugin and with its help found that the culprit is “UpdraftPlus” plugin: indeed, the “WP Mail Logging” plugin shows no “From” field in the header. Hera are the “raw” headers, with some fields masked for privacy:

    Time:
    July 23, 2018 10:07 pm
    Host:
    Receiver:
    ******
    Subject:
    Backed up: ******** (UpdraftPlus 1.14.12) 2018-07-23 22:07
    Message:
    Backup of: https://******* UpdraftPlus WordPress backup is complete. Backup contains: Files and database (Full backup) Latest status: The backup apparently succeeded and is now complete Email reports created by UpdraftPlus (free edition) bring you the latest UpdraftPlus.com news – read more at https://updraftplus.com/news/ * UpdraftPlus 1.14.12 Released (17 July 2018) * Plugin & Theme Manager from UpdraftCentral (4 July 2018) * WP-Optimize confirms it is developing a leading image compression feature (27 June 2018) * Easy Updates Manager 7.0.2 Released (20 June 2018) * MetaSlider 3.8.0 released (8 June 2018) * Top 5 AI driven m-commerce trends to watch out in 2018 (28 May 2018) Like UpdraftPlus and can spare one minute?: Please help UpdraftPlus by giving a positive review at www.ads-software.com. Review UpdraftPlus – https://www.ads-software.com/support/plugin/updraftplus/reviews/?rate=5#new-post
    Headers:
    X-UpdraftPlus-Backup-ID: 67079cff357f
    Attachments:
    Error:

    Now, what should be done? I searched UpdraftPlus’s support forum and found no complaints regarding missing emails. Is it just me? Or is this problem unique to UpdraftPlus/ WP Mail SMTP by WPForms combination?

    @slaffik,

    When using mailer SendGrid: In WP Mail SMTP, the test email works. In Contact Form 7, in the Mail tab…
    — if uncheck the “Use HTML content type” box, emails are sent OK as plain text, but end-of-lines are eaten (the message is sent in one paragraph);
    — if “Use HTML content type” box is checked, I get “There was am error trying to send your message. Please try again later” error.

    When using mailer MailGun: In WP Mail SMTP, the test email works. In Contact Form 7, in the Mail tab…
    — if uncheck the “Use HTML content type” box, emails are sent OK as plain text, but end-of-lines are eaten (the message is sent in one paragraph). This is same as with SendGrid.
    — if “Use HTML content type” box is checked all works well, the emails are sent with expected end-of-lines. This behavior is different than with SendGrid.

    Hope it helps.

    I confirm having the same issue.

    My workaround is: in Contact Form 7, in the Mail tab, uncheck the “Use HTML content type” box. Now the emails are sent OK via Contact Form 7 + WP Mail SMTP as plain text. There is another issue though: all end-of-lines have been eaten; the message is sent in one paragraph.

    Thank you @reddalek!

    Thread Starter ymf

    (@ymf)

    Thanks! Issue solved.

    Thread Starter ymf

    (@ymf)

    Found the culprit: the plugin “WP Cerber Security” disables the WP core functionality of redirecting a variety of shorthand URLs to the admin (as defined in the function wp_redirect_admin_locations() in the file canonical.php).

    Thread Starter ymf

    (@ymf)

    I had no changes to the permalink structure.

    mydomain/login returns HTTP Response Header Status: HTTP/1.1 404 Not Found. I.e., it does not redirect to wp-login.php.

    My other (test) site’s mytestdomain/login returns HTTP Response Header Status: HTTP/1.1 302 Moved Temporarily to Location: https://mytestdomain/wordpress/wp-login.php — even when I deactivate all plugins on that test site. There are no traces of this redirect in the test site’s .htaccess either.

    What mechanism is responsible for redirecting mytestdomain/login to https://mytestdomain/wordpress/wp-login.php?

    Thread Starter ymf

    (@ymf)

    Oops. Please disregard this topic. The switcher is there, didn’t see because of small font.

    Thread Starter ymf

    (@ymf)

    Sorry, I am not using Twitter…

    I don’t see the “show comment count” box in the plugin settings page at all. Would love to have it.

    Presently, the comments count is shown twice:

    One count from this WordPress plugin,

    Another count (on the next line) from the Facebook plugin.

    This is confusing. It would be nice to be able to control which count to show…

    Thread Starter ymf

    (@ymf)

    My host admin said the same, “php is preferable to curl/wget”.

    However, somebody here at WP forums says “run curl https://example.com/wp-cron.php is how you’re supposed to” (see here).

    Also, using the cd && php approach I occasionally (not every time) still get backup failures! Like this:

    0000.004 (0) Opened log file at time: Tue, 02 Jun 2015 08:07:02 +0000 on https://my-site-name.com/wordpress
    0000.008 (0) UpdraftPlus WordPress backup plugin (https://updraftplus.com): 1.10.1 WP: 4.2.2 PHP: 5.4.33 (Linux host.server.name 3.18.5-x86_64-linode52 #1 SMP Thu Feb 5 12:18:36 EST 2015 x86_64) MySQL: 5.5.42-cll Server: safe_mode: 0 max_execution_time: 900 memory_limit: 256M (used: 36.8M | 37.8M) multisite: N mcrypt: Y LANG: en_US.UTF-8 ZipArchive::addFile: Y
    0000.376 (0) Free space on disk containing Updraft’s temporary directory: 2446.5 Mb
    0000.392 (0) Tasks: Backup files: 1 (schedule: twicedaily) Backup DB: (schedule: twicedaily)
    0000.395 (0) Processed schedules. Tasks now: Backup files: 1 Backup DB: 1
    0000.404 (0) Requesting semaphore lock (fd)
    0000.407 (0) Semaphore (fd) was stuck, set lock time to 2015-06-02 08:07:03
    0000.409 (0) Semaphore (fd) reset to 1
    0000.411 (0) Set semaphore last lock (fd) time to 2015-06-02 08:07:03
    0000.412 (0) Semaphore lock (fd) complete
    0000.420 (0) Backup run: resumption=0, nonce=a356626773ad, begun at=1433232422 (1s ago), job type=backup
    0000.423 (0) Scheduling a resumption (1) after 300 seconds (1433232723) in case this run gets aborted

    0054.473 (0) Dropbox chunked upload: 100 % uploaded (rSrWdgvlr9IUJxd8c_rkMg, 1599058)
    0055.857 (0) Recording as successfully uploaded: backup_2015-06-02-0407_SITE_NAME_a356626773ad-themes.zip (eff7732ecf3c2506a75ecbc239872695)
    0055.864 (0) Deleting local file: backup_2015-06-02-0407_SITE_NAME_a356626773ad-themes.zip: OK
    0055.866 (0) Dropbox: File upload success (backup_2015-06-02-0407_SITE_NAME_a356626773ad-themes.zip): 1561 Kb in 4s (365 Kb/s)
    0056.259 (0) Dropbox quota usage: normal=581.2 Mb, shared=0 Mb, total=6144 Mb, available=5562.8 Mb
    0056.262 (0) Dropbox: Attempt to upload: backup_2015-06-02-0407_SITE_NAME_a356626773ad-uploads.zip to: backup_2015-06-02-0407_SITE_NAME_a356626773ad-uploads.zip
    0057.370 (0) Dropbox chunked upload: 20.4 % uploaded (7jHfys6vN4QrISa0vVD53Q, 1048576)
    0058.812 (0) Dropbox chunked upload: 40.7 % uploaded (7jHfys6vN4QrISa0vVD53Q, 2097152)
    0000.000 (1) Opened log file at time: Tue, 02 Jun 2015 08:16:02 +0000 on https://my-site-name.com/wordpress
    0000.003 (1) UpdraftPlus WordPress backup plugin (https://updraftplus.com): 1.10.1 WP: 4.2.2 PHP: 5.4.33 (Linux host.server.name 3.18.5-x86_64-linode52 #1 SMP Thu Feb 5 12:18:36 EST 2015 x86_64) MySQL: 5.5.42-cll Server: safe_mode: 0 max_execution_time: 900 memory_limit: 256M (used: 37M | 38M) multisite: N mcrypt: Y LANG: en_US.UTF-8 ZipArchive::addFile: Y
    0000.290 (1) Free space on disk containing Updraft’s temporary directory: 2435.9 Mb
    0000.294 (1) This backup task is either complete or began over 2 days ago: ending (1433232962.43, )

    So, I switched to the curl method.

    Thread Starter ymf

    (@ymf)

    David, I found the root cause! It was not the every-10-min vs. every-minute Cron job. It was the wrong cron command

    php -q /home/my-user-name/public_html/wordpress/wp-cron.php >/dev/null 2>&1

    With the above cron command, the short-running wp-cron jobs (not related to the UpdraftPlus) worked, but the long UpdraftPlus job was interrupted at 60th second and couldn’t even resume when called the next time.

    Once I changed the cron command to

    cd /home/my-user-name/public_html/wordpress && php -q wp-cron.php >/dev/null 2>&1

    the UpdraftPlus scheduled backups magically started working! No interruption at 60th sec.

    B.t.w. I verified two alternative cron commands:

    curl -s https://my-domain-name.com/wordpress/wp-cron.php?doing_wp_cron > /dev/null 2>&1

    and

    wget -q -O – https://my-domain-name.com/wordpress/wp-cron.php?doing_wp_cron >/dev/null 2>&1

    I wonder, do you have an opinion on which of the three above cron commands is preferable: cd && php, curl, or wget?

    Thanks Tim! I had a similar problem — an error message in the error_log file:

    WordPress database error Table ‘<db_name>.wp_wfHits’ doesn’t exist for query SHOW FULL COLUMNS FROM wp_wfHits made by require(‘wp-blog-header.php’), require_once(‘wp-includes/template-loader.php’), do_action(‘template_redirect’), call_user_func_array, wordfence::templateRedir, wordfence::doEarlyAccessLogging, wfLog->logHit, wfDB->queryWrite

    After delete-reinstall the plugin, the problem is gone.

    Thread Starter ymf

    (@ymf)

    David, I have a suspicion that my host’s Cron jobs are interrupted after 60 sec! Do you agree, looking at the following quotes from three logs?

    The log from the original post:

    0000.001 (0) Opened log file at time: Thu, 28 May 2015 01:30:03 +0000 on https://<domain&gt;.com/wordpress

    0058.193 (0) Deleting local file: backup_2015-05-27-2130_<site_name>_d535c18f7854-themes.zip: OK
    0058.196 (0) Dropbox: File upload success (backup_2015-05-27-2130_<site_name>_d535c18f7854-themes.zip): 1561 Kb in 4s (356 Kb/s)
    0000.000 (1) Opened log file at time: Thu, 28 May 2015 01:40:03 +0000 on https://<domain&gt;.com/wordpress

    Another log:

    0000.009 (0) Opened log file at time: Fri, 29 May 2015 15:30:05 +0000 on https://<domain&gt;.com/wordpress

    0054.814 (0) Dropbox chunked upload: 97.3 % uploaded (uZ9R4D5RRu1r_w5uKTg71Q, 23068672)
    0000.000 (1) Opened log file at time: Fri, 29 May 2015 17:10:04 +0000 on https://<domain&gt;.com/wordpress

    Yet another log:

    0000.003 (0) Opened log file at time: Sat, 30 May 2015 01:30:04 +0000 on https://<domain&gt;.com/wordpress

    0057.611 (0) Dropbox chunked upload: 20.4 % uploaded (BUMrKuaCpoSbtYMeLGXIYg, 1048576)
    0000.000 (1) Opened log file at time: Sat, 30 May 2015 01:40:04 +0000 on https://<domain&gt;.com/wordpress

    If my suspicion of a 60 sec cutoff on cron jobs is true, what can be done about that?

    To remind, I have the following:

    define('DISABLE_WP_CRON', true);” in wp-config.php,

    and in the Cpanel, I set an every-10-min Cron job with a command
    php -q /home/<my-user-name>/public_html/wordpress/wp-cron.php“.

    Thank you!

Viewing 15 replies - 16 through 30 (of 79 total)