Tag Archives: bugfix

jQueryUI Datepicker Calendar Control Visible at the Bottom of the Page CodeUnit 24 JUN 2011

For some or other annoying reason, my jQueryUI datepicker controls start exhibiting a weird bug where on page load, the normally hidden control calender was appearing right at the bottom of the page. Clicking on the launch control would then bring up the calendar correctly, and on selection or unfocus would then hide it again correctly. So only on page load then.

Luckily the fix to this annoying problem is actually nothing more than a simple CSS rule which you can add to the top of the affected page. (Note that this is after I spent a fair amount of time updating all my javascript plugins and trawling through the code to try and find the problem).

To solve, simply add:

#ui-datepicker-div { display: none; }

Yup, nothing more than that and your unwanted extra space at the bottom of the page is done for.

Nifty. (And yes, I still regard the jQuery and jQueryUI combo’s datepickers as one of the best ones currently available to website designers!)

Related Link: http://jqueryui.com/demos/datepicker/

WordPress Fix for Schedule Missed Posts CodeUnit 23 DEC 2009

After upgrading successfully to WordPress 2.9 the other day, I was mortified to find that all of a sudden all of my scheduled posts were being missed one after the other, and the only solution to actually force publish them was to hit the Quick Edit option on the posts listing page and change the each post’s status to published.

Needless to say, this is rather unacceptable.

Thankfully though, there is a fix for this particular problem, one that doesn’t involve installing a new plugin but rather depends on you editing one of WordPress’ internal files.

Now if we ignore the fact that your web host has suddenly and inexplicably gone and disabled your WordPress cron, we can assume that the problem lies in the cron (or scheduled task if you are from the Windows world) itself. As you might have noticed, WordPress seems to be getting slower and slower with each release, which is pretty natural when you think about just how much extra bells and whistles the developers keep having to throw at it in order to keep the ravenous horde that are its followers happy.

However, this could be exactly where the problem lies. If you go and locate the WordPress internal file /wp-includes/cron.php, opening it up and running a search for wp_remote_post should bring up a line looking something like this:

wp_remote_post( $cron_url, array(‘timeout’ => 0.01, ‘blocking’ => false, ‘sslverify’ => apply_filters(‘https_local_ssl_verify’, true)) );

(Hint: it’s around line 229 in a standard WordPress 2.9 config file)

If you look closely at the function call being carried out, you’ll notice that a timeout value of 0.01 seconds is being passed to the function, which is coincidentally exactly where the problem lies – the remote post is being adjudged to have timed out and thus aborted before it could actually run its job properly!

So the solution?

Well it is a simply matter of increasing that relatively small number of 0.01 to something more generous, like 20 seconds for example, meaning that the updated string should now look like this:

wp_remote_post( $cron_url, array(‘timeout’ => 20, ‘blocking’ => false, ‘sslverify’ => apply_filters(‘https_local_ssl_verify’, true)) );

Obviously you then need to save your changes and upload the saved file back to the server in order for it to be activated.