ColinABQ

Well, something seems to have changed, and it now appears to be working. Don’t mind me.

Thanks for the input, I appreciate it.

I also appreciate, and accept, some of the many reasons for it being a bad idea, a lot of the time. I just think that there enough instances of when it is a good idea, within the typical WordPress site, that it should become standard practice in most cases. Again, I think the www.ads-software.com and theme/plugin developer links should be considered augmenting and supporting.

I also acknowledge that it can be tough to figure when to do it, and when not to. The keys are, what content to consider augmenting, and somehow warning the user that new tabs or Windows will be used in those cases.

My rant wasn’t about keeping visitors at my site – my content needs to do that. My rant was about users, and me, having those links clobber whatever I was viewing or working on, and then having a heck of a time getting back there when I’m done with the augmenting or supporting information that was linked to. The www.ads-software.com and developer links are not, “please come read my stuff, it is much cooler than this” links, they are, “if you need help or want to know more about this, here you go.” I hope we can all understand that difference, and why at least some such links should launch in new Windows or tabs. Think of them the same way you think of “help” or “change your settings” pop-ups that some sites use.

Regardless, I’ve softened : ) We can all be right, to a degree.

Again, thanks.

Thanks for the input, I appreciate it.

I also appreciate, and accept, some of the many reasons for it being a bad idea, a lot of the time. I just think that there enough instances of when it is a good idea, within the typical WordPress site, that it should become standard practice in most cases. Again, I think the www.ads-software.com and theme/plugin developer links should be considered augmenting and supporting.

I also acknowledge that it can be tough to figure when to do it, and when not to. The keys are, what content to consider augmenting, and somehow warning the user that new tabs or Windows will be used in those cases.

My rant wasn’t about keeping visitors at my site – my content needs to do that. My rant was about users, and me, having those links clobber whatever I was viewing or working on, and then having a heck of a time getting back there when I’m done with the augmenting or supporting information that was linked to. The www.ads-software.com and developer links are not, “please come read my stuff, it is much cooler than this” links, they are, “if you need help or want to know more about this, here you go.” I hope we can all understand that difference, and why at least some such links should launch in new Windows or tabs. Think of them the same way you think of “help” or “change your settings” pop-ups that some sites use.

Regardless, I’ve softened : ) We can all be right, to a degree.

Again, thanks.

I don’t think it’s a bug … I think it is by design. It is simply a different type of hash, or perhaps encryption. $P and $B are no doubt directives of some sort allowing WP to detect which flavor of password mangling was used, and the rest looks a lot like base 64 — it might even be the original hash, base 64 encoded.

I did not mean to imply that anything was broken for me due to this — WP still works fine. The change does not lock anyone out of anything with my 2.7.1 ‘blog. It’s just different than in prior versions.

Another note: at least slightly cleaner than spewing whirled peas, I thought perhaps we could use “javascript:false” but that doesn’t work either.

I’ve found the problem, and it is a very strange one. For MSIE only, on line 219 of menu.js in the inove js folder, a script is injected:

document.write(‘<script id=”__ie_onload_for_inove” defer src=”javascript:void(0)”></script>’);

If we replace the void call with some impossible nonsense, the problem goes away and the code remains functional … as far as I can tell. In other words:

document.write(‘<script id=”__ie_onload_for_inove” defer src=”whirledpeas#”></script>’);

I have NO IDEA why IE would choke on the void call and insist that it is ‘insecure’ content, but that’s what it seems to be doing. I think. I admit that I do not understand this. The fix works in IE 6 and IE 8 (have not tested 7 yet, no reason to believe it would not work).

Perhaps someone can clarify why this is happening, and what a more elegant solution would be?

wildshot, thanks for the fix!
However, when I resized header_footer.jpg, the little vertical line didn’t line up. For me, I found it cleaner to replace header_footer.jpg with header_footer_1col.jpg, which is the same image but without that little bar.

For what it is worth, I see this as well and I do not have DingShow or any other such plug-ins installed. I was able to change a user’s password by simply pasting the ASCII hex md5 hash of the password into user_pass in the wpxx_users table, as indicated here, all over the ‘net. That worked. I was then able to log in to WP using the password I had used to generate the md5 hash. Great — so far, so good. But, then I all but immediately went back into the database and saw that the $P$Bxxxx format had been restored. This was observed less than 2 minutes after logging in using the new password. I do not know when it made the change, but it did.

Conclusions:
1. It is normal
2. It is a WP function, not a plugin.

Open issue/question: what methods are used to create the $P$Bwhatever values? If you investigoogle, you’ll find “attack code” samples out there, in dark places, that illustrate the methods, which involve salts and so on. It makes my head hurt, so I’m not going there. Hope I don’t need to. Still, I would be interested in the details, should WP ever choose to share them.