Forum Replies Created

Viewing 15 replies - 451 through 465 (of 504 total)
  • Gary,

    Try and add the following line to the wp-config.php file (if it does not already exist):

    define('ITSEC_USE_CRON', true);

    It may take some days before seeing any results. So be patient πŸ˜‰

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

    Below a bit of history about the scheduling constants used by the iTSec plugin in the wp-config.php file. It will probably help understand my reasoning:

    Old scheduling framework (pre 6.8.0 release):
    —————————————————–
    Default: page-load

    Alternative: cron
    Configured separately per module by defining the following constants in the wp-config.php file (and setting them to a true value):

    File Change Detection: ITSEC_FILE_CHECK_CRON
    Database Backup : ITSEC_BACKUP_CRON

    Not defining these constants was equal to setting them to false.

    New scheduling framework (6.8.0 release and newer):
    ———————————————————–
    Default: cron
    The former ITSEC_FILE_CHECK_CRON and ITSEC_BACKUP_CRON constants are deprecated.

    A single constant is used (ITSEC_USE_CRON) which IMHO should only be used to prohibit the iTSec plugin to use the default cron system for scheduling module tasks.
    Since cron is the default scheduling system it makes sense to assume that NOT defining the ITSEC_USE_CRON constant is equal to ITSEC_USE_CRON=true.
    But as I explained in my previous post that does not seem to be the case in the iTSec plugin 6.9.2 release. IMHO this is a bug in the itsec_cron_test callback.

    Alternative: page-load

    I think it’s also important to mention that you should always try to use cron for any scheduling activities. There are several obvious benefits to using cron to handle scheduled tasks as opposed to on page-load. iThemes rightfully switched to using cron by default in the iTSec plugin.

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

    The itsec_cron_test task is also a single event task which receives the scheduled execution time as an argument.
    If the result of the most recent itsec cron test event is negative the plugin changes the internal settings ‘use_cron’ to false and ‘cron_status’ to 0.

    		Default		Cron	No Cron
    		--------	-----	--------
    use_cron	true		true	false
    cron_status	-1		1	0

    (Where cron_status -1 is undetermined, 1 is available and 0 is unavailable).

    And this is exactly what I see happening. So why ?

    It turns out that in the itsec_cron_test callback the following code is executed:

    // Disable cron if the user hasn't set the use cron constant to true.
    if ( ( ! defined( 'ITSEC_USE_CRON' ) || ! ITSEC_USE_CRON ) && ITSEC_Lib::use_cron() ) {
    	ITSEC_Modules::set_setting( 'global', 'use_cron', false );
    }
    
    ITSEC_Modules::set_setting( 'global', 'cron_status', 0 );

    Notice the comment which says that cron should be disabled when the user has NOT set the ITSEC_USE_CRON constant to true.
    The condition that follows says: disable cron when the ITSEC_USE_CRON constant is not defined OR when it is set to false.

    Earlier we saw in the changelog that cron is now the default scheduling mechanism.
    (Which to me implicates that not defining the ITSEC_USE_CRON constant is equal to ITSEC_USE_CRON = true).
    Also the default value of the internal ‘use_cron’ setting is true …
    But the condition in the itsec_cron_test callback says disable cron when the ITSEC_USE_CRON constant is not defined. Clearly there is a contradiction here.

    So to fix this issue (or prevent it from happening) simply add the line below to your wp-config.php file:

    define('ITSEC_USE_CRON', true);

    Even though it is the default (preferred) scheduling system, if you want the iTSec
    plugin to KEEP using cron you HAVE to add the line above to your wp-config.php file.
    Also keep in mind, after adding the above line to the wp-config.php file, it may take a day for the next itsec_cron_test task to kickoff and correct the situation.

    Please note the above recommendation is for the 6.9.2 release only.
    If anything changes in a new release I’ll try and update this topic.

    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, 10 months ago by nlpro.
    • This reply was modified 1 year, 10 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, 10 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.

    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.

    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 ?

    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.

    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.

    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.

Viewing 15 replies - 451 through 465 (of 504 total)