Adding the Property Attribute to Style Sheet Declarations in WordPress for HTML5 Validation

HTML5 validator error

Of all the blogging platforms I’ve tried, WordPress is my favorite. If it is self-hosted, it is easy to customize.

One of the pitfalls of customization, however, is how easy it can be for a plugin of dubious quality to wreak havoc on your site. One of the problems I have had is that while WordPress does an excellent job at rendering valid HTML5 code, it is not difficult at all for a plugin to cause validation errors, even as a result of calling built-in WP functions.

In this case, a style sheet declaration was being triggered by a plugin using WP’s wp_register_style function. This function and the wp_enqueue_style function end up using the WP_Styles class, which is found in the /wp-includes/class.wp-styles.php file.

This class is called by WordPress and themes to insert link tags in the head section of your page. However, a plugin or theme can use the functions mentioned above to declare a CSS file anywhere on the page, inside or outside the head section.

This is not inherently problematic in that the page will be rendered normally. However, if the link tag is declared in the body of the HTML document rather than the head (as it happened in my case), the HTML5 code will not correctly validate if no property tag is present.

HTML5 validator error
No property attribute in a link tag not in the head? It won’t validate.

This line of code looks like it comes from a plugin, specifically the Comments Evolved (formerly known as “Google+ Comments for WordPress”) plugin. However, it is not – a little hacking on WordPress is in order here. Also, I’m going to report this as an issue so that the fix may be included in the next update.

If you open the file /wp-includes/class.wp-styles.php and add “property=’stylesheet'” to two lines (93 and 103 in my editor) as below, you shouldn’t see this problem again.

		$tag = apply_filters( 'style_loader_tag', "<link rel='$rel' property='stylesheet' id='$handle-css' $title href='$href' type='text/css' media='$media' />\n", $handle, $href );
		if ( 'rtl' === $this->text_direction && isset($obj->extra['rtl']) && $obj->extra['rtl'] ) {
			if ( is_bool( $obj->extra['rtl'] ) || 'replace' === $obj->extra['rtl'] ) {
				$suffix = isset( $obj->extra['suffix'] ) ? $obj->extra['suffix'] : '';
				$rtl_href = str_replace( "{$suffix}.css", "-rtl{$suffix}.css", $this->_css_href( $obj->src , $ver, "$handle-rtl" ));
			} else {
				$rtl_href = $this->_css_href( $obj->extra['rtl'], $ver, "$handle-rtl" );
			}

			/** This filter is documented in wp-includes/class.wp-styles.php */
			$rtl_tag = apply_filters( 'style_loader_tag', "<link rel='$rel' property='stylesheet' id='$handle-rtl-css' $title href='$rtl_href' type='text/css' media='$media' />\n", $handle, $rtl_href );

			if ( $obj->extra['rtl'] === 'replace' ) {
				$tag = $rtl_tag;
			} else {
				$tag .= $rtl_tag;
			}
		}

This will not fix any plugins or themes that use another mechanism to declare style sheets outside the head, but it has fixed several errors caused by plugins.

Using PowerShell to Check if a Particular User is in the Local Administrators Group

PowerShell 5.0 icon

PowerShell is a very powerful tool for Windows administrators and developers alike.

I wanted to find out if a particular user ID was in the local admin group on all servers in my domain. Fortunately, someone had written a script (source link no longer exists) to check that very thing on the server you’re logged onto.

However, I wanted to check not just the server I’m on, but on all servers in the domain.

The script below, called findadmins.ps1, should do just that:

$userToFind = $args[0] 

$servers = Get-ADComputer -Filter {OperatingSystem -Like "Windows *Server*"} -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack -Wrap -Auto

foreach ($server in $servers) {

	$administratorsAccount = Get-WmiObject Win32_Group -ComputerName $server -filter "LocalAccount=True AND SID='S-1-5-32-544'"
	$administratorQuery = "GroupComponent = `"Win32_Group.Domain='" + $administratorsAccount.Domain + "',NAME='" + $administratorsAccount.Name + "'`""
	$user = Get-WmiObject Win32_GroupUser -filter $administratorQuery | select PartComponent |where {$_ -match $userToFind}
	$user.PartComponent.Replace("\\","").Split("\", 2, [System.StringSplitOptions]::None)[0]

}

You should be able to run this at the PS command prompt like this, once you’ve changed to the directory where the script is: “.\findadmins.ps1 userid”.

I have not completely finished testing this, as I got a series of errors, though these errors do not appear to be due to errors in the script itself.

Why is this Website Garbled?

DIYthemes site on Chrome

I use Thesis from DIYthemes for this blog, and have found it to be a very versatile system for customizing their themes. However, I saw that my HTML 5 validation was failing due in part to the use of deprecated attributes on a link tag. I decided to report the problem via the DIYthemes website, and found something very strange!

DIYthemes site on Chrome
This is how the DIYthemes website looked on Chrome.

At first I thought that perhaps I had ended up on their page in a foreign language, or maybe their site had been hacked. When I viewed the HTML source, the text appeared as it should. If I selected some of the text and copied and pasted it into mt text editor, the missing letters were there! Perhaps a JavaScript was running that hid certain letters?

When I opened the page in Internet Explorer 11, the page looked correct:

DIYthemes on IE11
How the website looked on IE 11.

At this point, I took a look at the Chrome DevTools window (you can use F12 to get there) to see if that would yield the information I needed. I saw a warning in the Console pane that might lead to an answer: “Failed to decode downloaded font: data:application/font-woff…”

DevTools window on DIYthemes page
The Chrome Developer Tools window can be very helpful!

By turning off the font-family tags in the DevTools window, I watched the website begin to look normal, albeit in a more generic font than what the site is supposed to use. So apparently, if a font is not properly decoded by the browser, it can omit characters and cause the site to look like the first picture above.

I’m not yet certain why my Chrome browser did not decode the font, where IE 11 did. This could be a bug on the DIYthemes site, or a problem with Chrome. In any case, this error can happen for a number of reasons, and some of those reasons can be found on Stack Overflow.