Alvaro Degives-Mas

Looks related to what I also reported here; I’ve heard others saying the error message doesn’t reflect a problem with the minifying (or page caching) but I can’t tell for sure. I do think there’s a condition detection problem, i.e. that it’s an erroneous error message; a run of a few pages through e.g. Show Slow probably is a good indicator for you of whether there’s really a minifying issue.

Sure, just remember to hack it out on every update of the plugin.

Otherwise: I share the sentiment. Kudos to the author of an awesome and highly necessary plugin. Can’t thank Moggy enough!

Look in the theme, specifically the style.css file (unless you have a more or less complex theme, i.e. using several CSS / stylesheet declaration files) and tweak the statements to your pleasure.

If that sounds like gobbledygook, research and familiarize yourself with CSS. Or, hire the services of a qualified theme styler / artist to do it for you.

Check out either XVE or AMP; they are both neat little plugins differing in that AMP has settings for width and height for each of the supported video portals, while XVE allows you to set a unified size for all.

As to the flash block in the WYSIWYG editor, logic dictates you’re looking at that dangerous editor after entering the code in the HTML editor, and I’d think both Isptenu and yours truly already warned against that bad habit. So, don’t be surprised about the probability of the results. Also: the WYSIWYG editor has had that same issue since at least the WP2.x series. It’s not new. And as Isptenu also points out, technically it’s TinyMCE that which provides you the optimal rollercoaster experience whenever you mix point-and-click with nitty-gritty (and hardly standards compliant) HTML hard coding.

Which brings yours truly to briefly ponder the significance of your inapposite and broad brushed extrapolation in your parenthetical closing remark, rendering further comment obsolete past a casual observation that WordPress, along with many of its plugins and themes, are but a few examples of a quite selfless and open endeavor, placed in your hands for you to use as you see fit.

For free. By a global community of developers, who deserve a bit more appreciation than inappropriate projections and suppositions can afford.

Then go to Google and search for the term “search” first.

That’s not an issue specific to WP3.1 (or WP3.x for that matter) but has to do with WP attempting to “clean up” markup.

If you want simple and clean XHTML compliant video embedding, try one of the several outstanding plugin options out there, which allow you to embed a video (self-hosted or on one of the well-known video portals) with a simple shortcode / tag. Again there are several, so just FYI: I personally like XVE and AMP because they’re quite tiny and tidy (although Viper’s VQ is awesome too).

The plugin-less alternative is to remember to always embed in the HTML view, and to never change (edit) from the WYSIWYG editor any posts in which you have embedded code.

I’m glad you solved it. One tip: there’s a reason I recommended to rename, not delete via FTP, and after you have been readmitted (because AFDAS will have been deactivated upon login) to delete it from the backend.

If you delete the plugin directly via FTP, your IP address that got you locked out is still in the AFDAS internal cache of “bad” IP addresses. So, it’s tricky to deactivate / delete from FTP and then having to rely on your memory to disable the remote blacklist options. If you delete the plugin “properly” i.e. from the backend, AFDAS will also delete its database table, and thus clear out your IP address. Upon reinstalling it, you’ll have a clean slate again. That’s why I recommended it in that order.

As to dealing with the garbage: don’t expect silver bullets. They don’t exist. You have to apply a combination. I’ll copy and paste something said elsewhere:

don’t use one method. Use four. Or five. Use one from the trio of Akismet, TypePad AntiSpam and Defensio. Use something like WP HashCash. Use something like Bad Behavior. Use a tighter htaccess regime, e.g. by using BulletProof Security (it’s quite harmless in that it only deals with htaccess, not your WP install scripts). And use something wholly outside the WP box, like ZB Block (it’s very easy to set up in WP, just one snippet in two core files, drop a “WP compatibility file” in and you’re done.) Yet another option is CloudFlare, I can warmly recommend that, too. And finally, apply SSL certs to pages where people access your site via a login, forcing login sessions through encrypted tunnels (and if you really can’t afford SSL, use alternatives like Semisecure Login Reimagined together with login attempt limiters to thwart brute force attacks).

Dealing with the garbage is unpleasant for sure. But not dealing with it is even more unpleasant.