Lund

I have used Participants Database in the UK for years without any problems. However, very recently it has exhibited a lot of date related problems – dates out by one day, dates not saving, etc. I tried suggested solutions which have not worked, but have now found a fix after much trial and error with various settings.

Here are Original Settings:
WordPress Timezone: London
WordPress Date Format: d/m/Y
PD Strict Date Format: Checked
PD Input Date Format: dd/mm/yyyy
Sync php Timezone: Checked

Here Are the New Settings Which Fixed the Problems:
WordPress Timezone: UTC+0
WordPress Date Format: d/m/Y
PD Strict Date Format: Checked
PD Input Date Format: d/m/Y
Sync php Timezone: Checked

I am posting this in the event that this information may be of use to other PD users.

I have tried a number of plug-ins, but none can deal with these rows, especially if you are using a custom table prefix.

The best and perhaps only solution is to delete them manually using PHPMyAdmin. These session transient entries can be removed by running the following SQL queries. Note that you will need to use any custom table prefix that you may have on your database.

Query 1

delete from ‘wp _options’ WHERE ‘option_name’ LIKE (‘_transient_%’);

Query 2

delete from ‘wp_options’ WHERE ‘option_name’ LIKE (‘_wp_session_%’);

Thanks for the information. I have checked, and I am already using PHP sessions. So why would these rows be appearing, unless maybe PHP sessions aren’t working? (How can I tell if they are working?)

In any case, shouldn’t the transients be transient, and be automatically expired and deleted after a period of time? Many plugins work that way.

I tried disabling various options in iThemes, but none resolved the issue. It appears to be a conflict between the core code of the two plugins. I have alerted the developer of the Participants Database regarding the issue.

This is one of the occupational hazards of running so many plugins, I guess. I may have to look at other plugin solutions to give me the required functionality if these two plugins won’t play nicely with each other.

Thanks for the help dwinden.

Yes, I installed the latest iThemes plugin and the problem started. I have not used any older versions.

My preliminary testing has confirmed that you are correct about the Participants Database plugin. When this is disabled, the wp_options table does not grow with session transients.

As this appears to be a conflict between two plugins, what might the solution be? Do I need to choose between them, or is there a relatively quick fix that one or the other plugin developer might implement?

Here are some examples of full rows (two examples of each pair):

option_id option_name option_value autoload

322722 _wp_session_expires_60053d51cd9dd7b8921df2503790615a 1453238603 no

322721 _wp_session_60053d51cd9dd7b8921df2503790615a a:1:{s:14:”shortcode_atts”;O:21:”Recursive_ArrayAccess”:2:{s:12:”*container”;a:1:{i:1266;O:21:”Recursive_ArrayAccess”:2:{s:12:”*container”;a:0:{}s:8:”*dirty”;b:0;}}s:8:”*dirty”;b:1;}} no

322718 _wp_session_expires_2bfa05e02d292b0630f00412ec713bf1 1453238600 no

322717 _wp_session_2bfa05e02d292b0630f00412ec713bf1 a:1:{s:14:”shortcode_atts”;O:21:”Recursive_ArrayAccess”:2:{s:12:”*container”;a:1:{i:1266;O:21:”Recursive_ArrayAccess”:2:{s:12:”*container”;a:0:{}s:8:”*dirty”;b:0;}}s:8:”*dirty”;b:1;}} no

I have the following other plugins activated:

Admin Menu Editor Pro
Akismet
Anti-spam
Comment Move
Dashboard Notepad
Disable Emojis
Disable Revisions and Autosave
FormBuilder
Google Analytics by Yoast
iThemes Security
jQuery Responsive Select Menu
MailPoet Newsletters
Meta Slider
NextCellent Gallery
Optimize Database after Deleting Revisions
Participants Database
PayPal Donations
Redirection
Smart Youtube PRO
Surveys
The Bar Steward
TinyMCE Advanced
WordPress Database Backup
WP Hide Post
WP-Polls

I never had this problem until installing iThemes. Are there any known plugin conflicts that might be causing this behaviour?

Craig

The pairs of rows typically look like this:

_wp_session_4c1d8f112ee31fcec37dcf1651d456ec
_wp_session_expires_4c1d8f112ee31fcec37dcf1651d456ec

_wp_session_0346e9fda40b77ec252aa30531164237
_wp_session_expires_597a1a5fb2457fd573ad49663b6c84a4

And so on, one pair for each page view. When I disable the iThemes plugin, this behaviour stops. No further rows are added until I re-enable iThemes.

You can imagine how this bloats the database!

I deleted the old wp-cron file. Then I upgraded to 2.9.2. This resulted in the installation of a fresh wp-cron file. I then tested both future posts and post expirations using this plug-in. Both tests failed.

I understand that wp-cron is activated when any page is loaded. I tried loading pages which were set to expire and which were past their expiration, and they continued to load.

The new wp-cron file has no php closing tags. It just ends with die();

Do I need to configure anything in the wp-cron file? Or do I need to reset it somehow?

I tried setting up a future post, and that didn’t work either. The post is now marked ‘Missed Schedule’.

Next I will backup my website, and try upgrading to the latest WordPress version. Maybe that will install a new version of the wp-cron file and make this stuff work. I will report back.

Unless my web hosting company have something in place that stops wp-cron form working but maybe that is unlikely?

I should add that I am using the new 1.4 version of the plug-in.