HTTP Error 414 on WordPress

HTTP error 414

While trying to update the WP LinkedIn widget on a WordPress blog, I ran into an HTTP error I had never seen before: 414.

HTTP error 414 indicates that the URI is too long for the web server to interpret it.

In the case of a WordPress blog, this is likely caused by a security feature of the iThemes security plugin. If iThemes is being used, the first step would be to turn off the “Filter Long URL Strings” checkbox. This can be accessed through the WordPress admin console: Security –> Settings –> System Tweaks.

System Tweaks in iThemes Settings

The checkbox is about halfway down the page.

Filter long URLs checkbox

I would suggest turning this off only long enough to complete whatever administrative action you are doing, and then turning it back on, so as not to create an unnecessary vulnerability.

If you are not running iThemes, the setting is likely found in the Apache configuration, and may need to be addressed there.

Using CSS to Create Resizable Columns in WordPress with Thesis Theme…Part Deux!

CSS variable declaration and use

About three years ago, I wrote a post about dynamically resizing the content column in WordPress.org when using the Thesis theme.

The method described in that post worked fine until Thesis 2.4 was released last August. At that time, I noticed that my columns were no longer the full width of the window, and did not change size as I expanded or shrank the window. I sent an email to Thesis support and was told that a Box called Fix CSS would likely fix my problem. I installed it, but to no avail. Upgrading to Thesis 2.6 last month also had no effect.

Last week I decided to send another email and got a little more information. The creator of Thesis responded. Part of the message is below.

“Thesis 2.6 has ‘clarified’ the way you can use variables. Here’s how it works…

DO NOT:
Modify the Skin CSS, Editor CSS, or CSS Variables that come with your Thesis Skin. Whenever a Skin is updated, these three items will be overwritten, and you will lose any changes you’ve made to them.

DO:
Isolate ALL your CSS changes to the Custom CSS interface. Your modifications will be safe here during future Skin updates.
Create inline variables inside your Custom CSS interface, as seen in the image below:

picture of Custom CSS screen in Thesis

You can REFERENCE existing CSS Variables in your Custom CSS code, and you can also create and reference your own variables (like those shown in the image above) here as well.”

Now I had to implement the same steps as before in the previous post, but using this new method.

While the changes causing the builtin variables to revert to their original values may have been implemented in 2.6, my code had quit working at 2.4. So there’s a mystery! First, I removed the custom code and deleted the new variables from the Skin CSS so that it would be as it would directly downloaded the Thesis website.

Then, I basically set up new variables in the Custom CSS using the syntax shown in the screenshot above. I hit a snag here, however. For whatever reason, the CSS engine no longer supported the CSS calc() function! Also, I discovered that some of the CSS class names I originally used seemed not to affect the style of the column any longer.

The code below, which I appended to the bottom of my Custom CSS, does several things. First, it declares variables for the Custom CSS page in Thesis. Secondly, it implements those custom variables on the appropriate CSS classes and overrides the Skin CSS in all places where the variables $w_total and $w_content were used. Lastly, it declares a CSS variable to store the value in the builtin $w_sidebar Thesis variable. This will be useful in the next step, in which I will use a workaround for the lack of a working CSS calc() function.

$w_total_new = 80%;
$w_total_min = 897px;
$w_content_min = 585px;

.container, .columns > .content{
	max-width: $w_total_new;
	width: auto;
}

.landing .container{
	min-width: $w_content_min;
}

.full_width{
	min-width: $w_total_new;
}

.columns > .sidebar {
	max-width: $w_sidebar;
}

:root{
	--sidebar: $w_sidebar;
}

Since the modified $w_content variable in the original post used calc(), we’ll have to use the magic of JavaScript and jQuery to change the CSS after the page is loaded.

First, I grab the CSS variable called “–sidebar” by combining the window.getComputedStyle() method and the CSSStyleDeclaration.getPropertyValue() method interface.

I then trim the returned value to eliminate whitespace, and concatenate the string “-=” with the sidebar value which, incidentally, is currently 312px by default.

Then, I set the CSS to 100% for the classes listed. I then subtract (hence the “-=”) the sidebar width.

This:

$w_content = calc(100% - $w_sidebar);

Becomes this:

var sidebar = '-=' + window.getComputedStyle(document.body).getPropertyValue('--sidebar').trim();
if (sidebar==='-=') {
	sidebar = '-=' + window.getComputedStyle($('.sidebar')[0]).getPropertyValue('max-width').trim();
}
$('.landing .container, .columns > .content').css('width', '80%').css('width', sidebar);

Lastly, I wrapped it in a jQuery function that runs only after the window (including the CSS files) is fully rendered. The completed code below may be put in a Custom HTML widget in WordPress.

<script>
(function($) {
$(window).load(function() {
	var sidebar = '-=' + window.getComputedStyle(document.body).getPropertyValue('--sidebar').trim();
	if (sidebar==='-=') {
		sidebar = '-=' + window.getComputedStyle($('.sidebar')[0]).getPropertyValue('max-width').trim();
	}
	$('.landing .container, .columns > .content').css('width', '100%').css('width', sidebar);
	$('img').each(function(){
		var image = $(this);
		if(image.context.naturalWidth === 0 || image.readyState === 'uninitialized'){
		$(image).unbind('error').hide();
      }
	});
});
})(jQuery);
</script>

Voila! The content column is once again resizable!

Nota bene: This has only been tested on the Social Triggers skin for Thesis. Other skins may use different CSS classes, so YMMV.

Enabling SSL on WordPress Posts Automatically

SSL https

At the end of last year, I wrote about setting the Enable SSL checkbox on all past pages and posts. What I did not address was how to automatically set the Enable SSL checkbox automatically – you currently have to manually click the box. Hard, I know.

so difficult
…clicking that checkbox…

Nevertheless, I always like to find ways to automate mundane and repetitive tasks. In this case, I decided a trigger was in order!

First, I created a MySQL stored procedure to set the Enable SSL flag:

CREATE DEFINER=`username`@`localhost` PROCEDURE `sp_enable_ssl`(post_parent BIGINT(20))
BEGIN
	INSERT INTO `wp_postmeta` (post_id, meta_key, meta_value)
	SELECT post_parent, 'itsec_enable_ssl', 1
	FROM DUAL
	WHERE newpost_parent NOT IN (
		SELECT DISTINCT post_id
		FROM `wp_postmeta`
		WHERE meta_key = 'itsec_enable_ssl' and meta_value = 1 and post_id = post_parent)
	AND post_parent <> 0;
END

Then, I created an AFTER INSERT trigger and an AFTER UPDATE trigger, both of which use the stored procedure, in keeping with the DRY principle:

CREATE TRIGGER `wp_posts_trigger_insert` AFTER INSERT ON `wp_posts`
 FOR EACH ROW BEGIN
	CALL sp_enable_ssl(new.post_parent);
END
---------------------
CREATE TRIGGER `wp_posts_trigger_update` AFTER UPDATE ON `wp_posts`
 FOR EACH ROW BEGIN
	CALL sp_enable_ssl(new.post_parent);
END

I manually tested the triggers by updating and inserting into the wp_posts table, and the row that would enable SSL on the post got created.

However, when I actually tried saving a post in WordPress, nothing happened! I forgot to grant execute procedure permissions to the user with which WordPress connects to the database!

As it turns out, I am not granted SUPER privileges on my host, so I can’t grant any privileges. I would have two options, create the stored proc using the WordPress account, or to use the code in the stored proc in the triggers. In this case, I chose the latter option as it was much more practical than setting up phpMyAdmin as the WordPress user to do this. Should I ever need to do that, I’ll revisit this issue then.

The code for the triggers is below. Notice that there are differences from the code in the stored procedure, such as the use of “new.” to get values from the updated or inserted row in the wp_posts table.

CREATE TRIGGER `wp_posts_trigger_insert` AFTER INSERT ON `wp_posts`
 FOR EACH ROW BEGIN
	INSERT INTO `wp_postmeta` (post_id, meta_key, meta_value)
	SELECT new.id, 'itsec_enable_ssl', 1
	FROM DUAL
	WHERE new.id NOT IN (
		SELECT DISTINCT post_id
		FROM `wp_postmeta`
		WHERE meta_key = 'itsec_enable_ssl' and meta_value = 1 and post_id = new.id)
	AND new.post_parent = 0 AND new.post_type='post';
END
-------------------
CREATE TRIGGER `wp_posts_trigger_update` AFTER UPDATE ON `wp_posts`
 FOR EACH ROW BEGIN
	INSERT INTO `wp_postmeta` (post_id, meta_key, meta_value)
	SELECT new.id, 'itsec_enable_ssl', 1
	FROM DUAL
	WHERE new.id NOT IN (
		SELECT DISTINCT post_id
		FROM `wp_postmeta`
		WHERE meta_key = 'itsec_enable_ssl' and meta_value = 1 and post_id = new.id)
	AND new.post_parent = 0 AND new.post_type='post';
END