Forum Replies Created

Viewing 15 replies - 496 through 510 (of 546 total)
  • kot41

    If you prefer not to be notified by email of any follow-up replies please unsubscribe from this topic.

    Ok, that’s great. However …

    Remember I mentioned something about a quirck in the plugin hooking into WP Cron ?

    I was able to identify the cause and find a simple (non code) solution as well.
    Before posting an explanation I think it is usefull to read 2 relevant quotes from the 6.8.0 changelog:

    • New Feature: Introduces a scheduling framework for handling events. Cron is now used by default, and will switch to using an alternate scheduling system if it detects an error. To disable this detection set ITSEC_DISABLE_CRON_TEST in your wp-config.php file.
    • Important: The ITSEC_FILE_CHECK_CRON and ITSEC_BACKUP_CRON constants have been deprecated. Use ITSEC_USE_CRON instead.

    The important parts from these 2 Changelog entries are ‘Cron is now used by default‘ (which means it is the preferred method of the iTSec plugin for scheduling tasks/events) and ‘Use ITSEC_USE_CRON instead‘.

    So when the ITSEC_USE_CRON constant is not defined (at all) or defined and set to true (in the wp-config.php file) the iTSec plugin will use the WP Cron system for scheduling tasks/events. It’s important to note that NOT defining the constant seems to be equal to defining it and setting it to true (do note this is my personal opinion based on the available documentation so keep in mind I could be wrong).

    Ok, so initially the iTSec plugin hooking into WP Cron seems to work fine without setting any related constant. But I noticed that after a short while the plugin stops hooking into WP Cron. The tasks scheduled by the iTSec plugin in WP Cron mysteriously disappear. Below is a list of the iTsec cron tasks I noticed initially:

    Name			Schedule	Arguments
    itsec_cron_test		False		1524611447
    itsec_cron		Daily		file-change
    itsec_cron		Daily		clear-locks
    itsec_cron		itsec-backup	backup
    itsec_cron		Daily		purge-lockouts
    itsec_cron		Daily		purge-log-entries
    itsec_purge_logs*	Daily		

    *This is a leftover from an earlier iTSec plugin release which iThemes forgot to cleanup … Add the following line to your active theme functions.php file to get rid of it:

    wp_clear_scheduled_hook( 'itsec_purge_logs' );

    As you can see iThemes switched to a more abstract scheduling system where all the tasks are named identically (itsec_cron) but the arguments passed to the cron task determines which task is to be executed.

    Notice there is 1 task that has a different name: itsec_cron_test.
    It seems iThemes includes this task to check whether the WP Cron system is functioning properly.

    Stay tuned, this post is to be continued …

    • This reply was modified 1 year, 11 months ago by nlpro.
    • This reply was modified 1 year, 11 months ago by nlpro.

    Is that in the Opera browser ? If so, did you try from any other browser (Google Chrome, Mozilla Firefox, MS Internet Explorer) ?

    Oh and the Settings page layout does not exhibit the same problem ?
    (Which would be odd as both pages make use of a similar layout).

    • This reply was modified 1 year, 11 months ago by nlpro.

    If the cron job doesn’t kick off try to deactivate/reactivate the plugin. There seems to be a quirck in the plugin hooking into WP Cron.

    iThemes removed it when they refactored the Logs page in the 6.9.0 release.

    However as of the 6.9.2 release the plugin includes a cron job that will clean the log daily in the background.

    Use the Days to Keep Database Logs setting in the Global Settings module to specify how much data is to be kept (default 14 days). If you specify 0 the log is automatically emptied somewhere between now and 24 hours. Once the log is cleared, don’t forget to reset it to a non 0 value.

    For any previous releases visit the Development page and then click on the Advanced View link. Scroll to the bottom of the page and voila there it is.

    Or jump straight there from here.

    Check for the DISALLOW_FILE_EDIT define in the wp-config.php file.

    Temporarily deactivating the plugin is a simple way to determin whether it is the iTSec plugin causing the issue.

    nlpro

    (@nlpro)

    Hmm, it seems WordPress core wpdb class needs patching. Trac ticket #32315 covers the whole issue and even includes a preliminary patch. Forget about trac ticket #32167 I mentioned earlier 😉

    This certainly makes an interesting read.

    nlpro

    (@nlpro)

    Just a quick update:

    Trac ticket #32167 seems to be relevant for this issue.

    It seems like there have been some changes to the core wpdb class in WordPress 4.2.0 which can lead to situations like this one.
    However if iThemes ensures the data to be inserted fits the database this would not be an issue.

    Question is: Does WordPress core wpdb class need patching or should iThemes perform sanity checks before inserting data ?

    nlpro

    (@nlpro)

    So it means this changes is from their side ?

    Yes, the entire code of the Hide Backend feature was rewritten in the 6.3.0 release.

    nlpro

    (@nlpro)

    According to the 6.3.0 Changelog:

    Important: The way that Hide Backend functions changes in this release. Previously, if your Hide Backend Login Slug was wplogin, going to example.com/wplogin would result in the URL remaining example.com/wplogin. The new implementation of this feature results in a redirect to a URL that looks as follows: example.com/wp-login.php?itsec-hb-token=wplogin. While this may not be desireable for some users, this change was necessary to fix longstanding compatibility issues with other plugins. Once you access the login page using the Login Slug page, a cookie is set with an expiration time of one hour. As long as the cookie remains, you can access example.com/wp-login.php without having to access the Hide Backend Login Slug first. If you wish to confirm that Hide Backend is working properly on your site, opening up a private browsing window is a quick way to test without having to log out and clear cookies.

    nlpro

    (@nlpro)

    According to Codex wpdb class doc:

    If the length of a string element in the $data array parameter is longer that the defined length in the MySql database table, the insert will fail, this function will return false, but $wpdb->last_error will not be set to a descriptive message. You must ensure the data you wish to insert will fit in the database – do not assume the MySql will truncate the data.

    Note the above quote is taken from the $wpdb->replace method. But it also applies for the $wpdb->insert method.

    nlpro

    (@nlpro)

    Hmm you got me confused … (i think).

    WordPress adds the “ver=“ query string for a reason. Cache busting.
    If a new WordPress version is released which includes a modified resource the old resource from (browser) cache is ignored. Thus making sure the modified resource is automatically loaded …

    So how does a proxy caching server know when to serve a modified resource when there is no query string? Oh wait, when it’s encoded into the url the new url will be different … right ?

    So basically WordPress is doing it wrong !??

    Just trying to learn something from this …;-)

    nlpro

    (@nlpro)

    That will add the following entry to the .htaccess file as can be seen in Settings > Advanced (link) > Show Details (button) of the Server Config Rules module:

    # Ban User Agents – Security > Settings > Banned Users
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTP_USER_AGENT} ^site\.ru [NC]
    RewriteRule ^.* – [F]
    </IfModule>

    Notice the HTTP_USER_AGENT string in bold which should be HTTP_REFERER … So in this form it’s not going to do what you aimed for. However if you manually replace HTTP_USER_AGENT with HTTP_REFERER it’s ok. Do realize when making use of the Ban User Agents feature to generate these lines they may be regenerated by the iTSec plugin at any moment which will undo any customization applied.

    You better add all of these lines manually to the .htaccess file as suggested earlier in this topic.

    The above is just my opinion and not iThemes.

    nlpro

    (@nlpro)

    Any personal information is stored by WordPress and that, in terms of GDPR, is being looked at in the WordPress core group.

    You can see that on the make.core blog via this tag.

    https://make.wordpress.org/core/tag/gdpr-compliance/

Viewing 15 replies - 496 through 510 (of 546 total)