Forum Replies Created

Viewing 15 replies - 1 through 15 (of 47 total)
  • Hi @mbrsolution,

    Thank you for your immediate reaction! Here are the answers to your questions:

    1. In Settings > General > Membership, ‘Anyone can register’ is disabled.

    2. Firewall rules enabled:
    – Basic Firewall Protection
    – Completely Block Access To XMLRPC enabled

    3. Brute Force:
    – Enable Rename Login Page Feature NOT enabled

    So far I had not used the Rename Login Page feature because I do use server caching. However, I can understand that this helps preventing ‘automated’ login attempts, so I think I should look into it again.

    Thank you!

    Do you have any idea where the lots of very different (random?) IP-addresses can come from?

    @mattyrob

    You are a hero! I installed and tested your fix: problem solved.

    Thank you very much!

    Thank you for your reaction.

    I think you misunderstood. The options at the bottom of the Dashboard > Settings > General page are about the date and time FORMAT but that is not the issue. My message is about the date and time LANGUAGE.

    For example: my date setting on the Settings page is ‘j F Y’. Underneath the date setting box is a preview example:
    – when the back-end language (administrator account language) is English, it says 23 March 2018
    – when the back-end language is Dutch, it says 23 maart 2018

    At the front-end, if the site language setting is Dutch, you always see the date represented as 23 maart 2018 (in the post entry-meta, for example), independent of any administrator account language setting.

    In the email messages produced by Subscribe2 this is not the case. The date is correctly in the format ‘j F Y’ (as you wrote), but incorrectly (I think) in the language of my administrator account instead of the site language.

    I hope this is clear now?

    Hello,

    Ok, this has been SOLVED, thanks to @trsmith3.

    I indeed used an archive name of the format backwpup_[whatever]_%hash%, to be precise: backwpup_%Y-%m-%d_%H-%i-%s_%hash%. I used this so that sorting the file names in alphabetical order implied sorting them in time.

    I changed this into: backwpup_%hash%_%Y-%m-%d_%H-%i-%s. For testing I also changed the number of backups to be kept to 2 (both local folder and Dropbox) and ran the backup job four times. I found that now only the two most recent copies are kept; earlier backups (with the same file name format) are automatically deleted.

    So this is indeed a problem with file names – undocumented, I think; I only see that ‘%hash% must be included anywhere in the archive name’.

    Thank you!

    Yes, of course, but the screenshots and logfile contain some security-sensitive information that I do not want to make available through a public media like the WordPress support pages.

    @duongcuong96

    Sorry, I have been away. I now have a zip-file with 11 screenshots of the job configuration and a debug log file. Please let me know how to send it to you.

    @duongcuong96

    Debug information from BackWPUp > Settings > Infomation > Get Debug Info below.

    Created and ran new job that backs up to the same folder on Dropbox: new file created, no old file deleted.

    Thank you for your help; hope this is useful

    ————————————————————-

    WordPress version: 4.9.5
    BackWPup version: 3.4.4
    PHP version: 7.1.16 (64bit)
    MySQL version: 5.6.36-82.1-log
    cURL version: 7.53.0
    cURL SSL version: OpenSSL/1.0.2k
    WP-Cron url: https://bcstar.nl/wp-cron.php
    Server self connect: Response Test O.K.
    Document root: /home/bcstar31/public_html
    Temp folder: /home/bcstar31/public_html/wp-content/uploads/backwpup-566b45-temp/
    Log folder: /home/bcstar31/backups/logs/
    Server: Apache
    Operating System: Linux
    PHP SAPI: cgi-fcgi
    Current PHP user: bcstar31
    Maximum execution time: 300 seconds
    Alternative WP Cron: Off
    Disabled WP Cron: Off
    CHMOD Dir: 0755
    Server Time: 13:56
    Blog Time: 15:56
    Blog Timezone: Europe/Amsterdam
    Blog Time offset: 2 hours
    Blog language: en-US
    MySQL Client encoding: utf8
    PHP Memory limit: 768M
    WP memory limit: 40M
    WP maximum memory limit: 768M
    Memory in use: 8.00 MB
    Loaded PHP Extensions:: Core, PDO, Phar, Reflection, SPL, SimpleXML, Zend OPcache, bcmath, bz2, calendar, cgi-fcgi, ctype, curl, date, dba, dom, enchant, exif, fileinfo, filter, ftp, gd, gettext, gmp, hash, iconv, imap, intl, json, ldap, libxml, mbstring, mcrypt, memcached, mysqli, mysqlnd, openssl, pcntl, pcre, pdo_mysql, pdo_pgsql, pdo_sqlite, pgsql, posix, pspell, readline, session, shmop, soap, sockets, sqlite3, standard, sysvmsg, sysvsem, tidy, tokenizer, wddx, xml, xmlreader, xmlrpc, xmlwriter, xsl, zip, zlib

    Hello,

    Thank you for handling this so quickly.

    Thanks also for offering to send me a fix, but there is no need. I already fixed it (in a way that is good enough for me) in my copy of slider_front_end.html.php

    Best regards,
    Henk

    Hello Cory,

    Thank you. I submitted a support ticket, as you suggested.

    Please note that, in my view, this is only a small bug; I can very well live with having to delete packages one by one :-). I brought it up because I assumed you want to be aware of this and remove it in case it would be a easy to fix. Just a small thing to do in return for the great Duplicator plugin you allow me to use.

    So there is no urgency at all, as far as I am concerned. If you need any further information (“I can look at your setup”), I will be happy to help.

    Hi Cory,

    That’s quick! 🙂

    I just tried on Firefox, IE 11 and (on a different computer) the new Edge browser. Cleared history first. All the same result, as described.

    Thanks!

    Hello Bernhard (and others),

    I am very sorry, please ignore this post.

    I have tried Backend Localization but found that it did not do the few things I wanted, so I moved away to another plugin, WP Native Dashboard.

    Later on I somehow mixed the two up, resulting to the above request, based on a misunderstanding.

    Henk Barreveld

    Hi Cory,

    Ok, I submitted a ticket with all the information.

    Hi Cory,

    If you would be interested to find out where exactly SiteGround (and possibly others as well) has a problem with the Duplicator build process, I will be happy to support you.

    Suppose I create a subdomain on one of my SiteGround accounts and create a MySQL database. I give you an FTP account to access the subdomain and the parameters to access the database. Then you can do tests for some time with a minimal WordPress installation with Duplicator, adding debug code etc.

    What do you think?

    @photomaldives:

    Yes, I also wondered if disabling rule 1838 in mod_security would create any security risks. However, I decided that I would take the risk, assuming that the ISP’s support team knows what they are doing.

    It would of course be best if Cory could take a look at his code, to see if it does anything (maybe setting permissions higher temporarily?) that could cause a mod_security firewall to protest.

    @cory:

    Does the above make sense to you? I tried to find out from SiteGround support what their rule 1838 is about but, understandably I suppose, they are somewhat evasive on that issue 🙂

    @marwazihs:

    I recommend doing what the error message recommends you to do (if you indeed get the same error message):

    …contact your host support team and provide detailed instructions how to recreate this error.
    They will be able to assist you with rectifying the problem and adjusting the security configuration if needed.

    I wish I had done that myself, rather than spending hours trying to find if I had done something wrong.

    Hello everybody,

    Problem solved 🙂

    I sent a message describing my last test to SiteGround Support at around the same time I sent message #7 above.

    First reply, after a few minutes:

    There are no changes with our security settings for our shared servers.

    … but they would look into it further, using the admin login I gave them.

    Half an hour later a support guy sent me the below message with a solution:

    I have checked and noticed that the issue was caused by a security rule of one of our modules.

    I have added the following to the .htaccess file in your home folder to deactivate the problematic rule for your entire account:

    <IfModule mod_security.c>
    SecFilterRemove 001838
    </IfModule>

    I have then performed another test and the issue was resolved.

    I checked as well, also on the “real” website; The Duplicator Build process is working again.

    By the way, wonderful service, if you ask me. I only have the lowest price shared hosting account without any additional support options.

Viewing 15 replies - 1 through 15 (of 47 total)