Displaying 1 To 5 Of 5 Comments Some Orgnizations And WordPress Just Don’t Mix @Kevinjohn Gallagher — That’s unacceptable behavior, and I thoroughly condemn any harassment you’re receiving. (Said as much here, and RT’d from @WordPress). To anyone who is participating in this kind of bullying: knock it off. I had some substantial disagreements with Kevinjohn’s post too, but this is not how adults handle disagreements. You’re making us all look bad. Stop it. Here are your options: ignore the post, rebut the claims in his post, or (if you think they’re valid criticisms and worth fixing in WordPress) make them obsolete by contributing to the project. » Posted By Mark Jaquith On January 15, 2012 @ 5:00 PM Narrowly Escaping WordPress 3.0.6 one of the security fixes for 3.0.5 created another problem of stripping HTML on display from people with the It’s much, much more specific than that. It only affects advanced HTML (like image tags, which are normally forbidden) in comments made by Editors or Administrators on single-site WordPress installs. So it makes them behave like multisite installs, which forbid everyone from posting advanced HTML in comments. And it only does it on display, so there is no data corruption. Most people don’t even know that Editors and Administrators can post images etc into comments. It’s not a frequently used thing. We decided that although it was frustrating that the bug slipped in, it was not severe enough to warrant another release. The Akismet team was planning a release that day anyway, so we asked them if they’d be willing to incorporate a quick hotfix into the new version. But I also wanted to offer a standalone solution for the minority of installs affected that didn’t require activating Akismet. So, as I’ve done in the past, I created a Hotfix plugin. Except this time, instead of targeting the entire plugin to a specific release, I made it generic, so that it can push other “not worthy of a release by themselves” fixes to people sooner than they’re otherwise get them. It’s opt-in. It doesn’t change our release decisions. It’s just a more attractive solution than “use subversion” for people who are affected by the bug. I don’t want to bundle any new plugins with WordPress. Quite the opposite. Plugins have their own update procedures and release schedules and I think that plugins should be omitted from core updates. Maybe even from the package (note: just my opinion, there). We’re going to be discussing that (and many other things related to updates) in the 3.2 cycle. » Posted By Mark Jaquith On February 9, 2011 @ 8:12 PM WPWeekly Episode 96 – Commercial Services To answer an issue that came up: no, I don’t have any hand in WordPress.com goings-on. If there is a patch for WordPress core that we want tested, Ryan Boren may roll it out on his WordPress.com testbed, but none of the non-Automattic contributors have access to WordPress.com code. Similarly, Automattic employees don’t get automatic commit access to WordPress core just because they might have access to WordPress.com. They have to earn that just like anyone else. Look in Trac to see Automattic employees submitting patches to WordPress core, without any unearned consideration. There are two main things that make this separation fuzzy: Matt, and the naming issue. The naming issue is sort out out of the bag, unless Automattic starts using its wp.com domain instead of WordPress.com. And the Matt issue is simply that because he founded Automattic and was a co-founding developer on WordPress (and is the bottom line when it comes to the WordPress.org site), people think that he’s unable to “change hats,” so to speak. That’s just something you’ll have to judge by his actions. And even the non-Automattic WordPress core developers have to deal with the issue of objectivity. I get asked all the time whether I can use my influence over WordPress core to promote a plugin, a company, a service, or commit a feature or patch that would benefit one group to the detriment of another. My perspective, and I’d wager other WordPress core devs would agree, is that WordPress is more likely to outlast any one company or client, and selling WordPress up the river for some short term gain would be a really stupid move. » Posted By Mark Jaquith On April 21, 2010 @ 1:56 AM Comment_karma is a remnant. To my knowledge it has never been used, not even by b2. So it’s not so much a remnant as a “there if you want to use it” thing. We’ve discussed two possible uses for it over the years. One was using it for an anti-comment-spam system where multiple plugins could bump the karma up or down based on different factors, and the end result could be stored there. This was prior to the concept of storing “spam” comments in the database. Then Akismet came on the scene, and it worked better than open source rulesets, so the idea of a hoard of anti-spam plugins has faded. The other one way Digg or Slashdot style comment ratings (not for core, but for plugins to use). That seems to be more or less the way True/Slant is using it, albeit with only two levels and editorial control of the ratings. » Posted By Mark Jaquith On February 27, 2010 @ 5:09 AM WordPress Dev Chat For 9-10-09 Auto upgrade replaces all the files, and likely will continue to do so. It’s good practice, as it is the best way of ensuring that you have a clean, complete WP install. The “changed/added files only zip” can be downloaded manually from Trac by people who cannot use the auto-upgrade, and who don’t want to manually upload an entire WP install when only some of the files have changed. It’s not going to be a canonical upgrade method — it’s just a handy shortcut for a small group of people. » Posted By Mark Jaquith On September 13, 2009 @ 4:26 AMComments Posted By Mark Jaquith
unfiltered_html capability
«« Back To Stats Page