css-related bug found in media.php

[LHLDevAdmin]

I'm writing to report a non-critical, css-related bug found in WordPress. The bug does not prevent pages from loading, but does cause w3c validation errors under certain circumstances.

I have thoroughly documented this bug online, which includes links to verifiable data. To access this blog post, please visit on the web site: ​http://www.lhl.uab.edu/lhldev/?p=5 .

In the following lines, I will provide a summary and highlights from the aforementioned blog post:

When a contributor adds an image gallery to his/her post, the "gallery_shortcode($attr)" function of the "media.php" file (/wp-includes/media.php) inserts internal style sheet code into the body of the page. Since internal style sheet references are called from the head tag, this action results in a w3c validation error.

The solution is simple, but completed in a few steps.

Step 1: Remove the style sheet code from the "$output = apply_filters()" [SEE: lines 427-442] -- keeping only the comment and div tag.
Step 2: Create a theme-independent style sheet, which can reside in "/wp-includes/."
Step 3: Add the gallery's style selectors, properties and values, which were removed in the Step1 (SEE: ABOVE) to this file.
Step 4: Add a reference to this newly created style sheet in "header.php" (/wp-content/themes/default/header.php) and any other file, which includes header information. To preserve the functionality of all theme-based style sheets, this css reference should be positioned above the following code: <link rel="stylesheet" href="<?php bloginfo('stylesheet_url'); ?>" type="text/css" media="screen" />

You folks create great code, so I will not make further recommendations on how to implement this correction. Personally, I like the theme-independent style sheet concept because it allows WordPress designers to define some global styles for the site. Theme developers have the option of preserving the original style parameters or overwriting them within their own theme-based style sheets respectively.

Please feel free to contact me directly if you have any questions.

Thanks,
LHLDevAdmin

[LHLDevAdmin]

Additional information:

In addition to making a meaning contribution to an invaluable blog site software, I'm reporting the error at the recommendation of our server administration staff. Generally, we are discouraged from making any code modifications outside of the /wp-contents/ sub-directory to minimize overhead. As has already happened on a few occasions, WordPress updates to our servers have resulted in the restoration of the original media.php file. Thanks again,

[LHLDevAdmin]

Sorry, feel free to contact me via email at rstims@….

[LHLDevAdmin]

The version is actually 2.6.3, but I don't see that listed in the version drop-down menu

[mrmist]

Is this not done by design? I mean yes it does seem syntactically broken, but isn't that inline style stuff only pushed if a plugin has specifically overriden it?

I guess it could all be punted to a dynamically-generaed stylesheet, though that might be really complicated to achieve.

[LHLDevAdmin]

Replying to mrmist:

Is this not done by design? I mean yes it does seem syntactically broken, but isn't that inline style stuff only pushed if a plugin has specifically overriden it?

I guess it could all be punted to a dynamically-generaed stylesheet, though that might be really complicated to achieve.

I'm not sure whether I'm reading sarcasm or frustration, so I'll assume the latter.

I'm not sure of the technical definition of 'plugin,' by which you operate, but one would think the image gallery option within WordPress is part of the software. Therefore, one should not present 3rd-party plugin excuses as arguments against doing something correctly. If I wanted software that selectively adheres to web-compliance standards, then I'd buy a Microsoft product.

Undoubtedly, a dynamically-generated style sheet would be complicated to achieve, and I'm not suggesting you try it. However, examples abound where master and theme-based style sheets working together successfully within the application. In those examples (MS SharePoint comes to mind), the master style sheet is not dynamically generated; rather, they are deployed with the software and re-deployed with each software version update.

With a master style sheet, which sets above the themes sub-directory within the site structure, you could include all styles associated with your plugin (meaning those deployed with the software). This style sheet, like all other software-related files within WordPress, can be overwritten with each version update.

As long as WordPress uses class tags to call the styles, I can (where needed) write code (at the theme level) to override the master styles. Under the current deployment scenario, I'm forced either (a) to accept sloppy coding or (b) to modify the software after every WordPress update.

[Denis-de-Bernardy]

once #7678 is fixed, it'll make sense. closing as dup, as there are tons of similar tickets.