Displaying 1 To 30 Of 77 Comments Secrets Revealed: WLTC and WPTavern @Jeffro – It’s possible to do hangouts as just audio, though the video integration with YouTube is nice too. YouTube does let you download the recorded video from the Hangout, and extracting the audio from that is relatively easy. Certainly worth a try. » Posted By Otto On May 21, 2013 @ 4:02 PM New Company Releases Evil WordPress Plugin Please, don’t feed the trolls. » Posted By Otto On May 10, 2013 @ 7:10 AM Up To The Community To Improve Theme Demo Data @Chip Bennett – “Supporting featured images wouldn’t be as easy or trivial as you imagine.” Sure it is… if I want it to do image resizing on the fly, I’ll just use Photon. :) » Posted By Otto On May 9, 2013 @ 12:06 PM 300 Free Icons For Web And User Interface Design Unfortunately, that license is not GPL-Compatible, and so the icon set cannot be used in any themes or plugins hosted for free on WordPress.org. “Do not sell the icon set, host the icon set or rent the icon set (either in existing or modified form).” is not a GPL-Compatible statement. Freedom means allowing other people to do things with the creative work too, even things you might not like. » Posted By Otto On November 27, 2012 @ 11:20 AM What Dev4Press Thinks WordPress Needs I don’t disagree with any particular thing there, but that is a very developer oriented list. Improvements in UX affect far more people in the short term. » Posted By Otto On April 16, 2012 @ 6:28 PM One Way To Make WordPress Less Portable BTW, I would be perfectly happy to have the entire core stop using serialized PHP variables for *anything* and start using JSON encoded data instead. This wouldn’t suffer from the length changing issue, and JSON is far more widely portable. If anybody wants to try to convince others, I’ll agree with you. :) » Posted By Otto On April 11, 2012 @ 11:32 AM They don’t really explain the issue properly. The issue is not with serializing data and putting it in the database. That is actually fine, for certain specific kinds of data. Not every kind of data is something that needs to be searchable using a relational database model. The settings for a plugin, for example, are generally stored serialized. The issue happens when you store URLs or local directory paths in serialized data. People who are migrating sites from one URL or server to another might try the naive approach of doing an SQL dump, doing a search/replace on that dump, and then importing the dump to the new site. When they do so, they’ll find that serialized data which they modified will be gone, because they forgot to change the length values to match correctly. The solution is to make smarter search-replace mechanisms, or better yet to simply not store URLs and directory paths in serialized data. The WordPress core tries to avoid this, though it has not always been successful. If you find a place in core where URLs and such are being stored in a serialized format, the core team considers that a *bug* and would appreciate a ticket and/or a patch to that effect. Migrating sites in that “naive” way is something you shouldn’t be doing anyway, IMO, but that’s a whole different argument… There’s better ways to set up your dev/staging/production environments, without needing to change URLs around. » Posted By Otto On April 11, 2012 @ 11:29 AM New Ebook Released For WP Multisite Ryan: It’s best to use the right license for the right purpose. The GPL is designed to be a license for code. It doesn’t make sense when interpreted for something like textual content, or images, or other types of creative works. For those, a different license might be more appropriate. Not that you can’t apply any license to any work, it’s just unclear as to intent in some cases. CC license are great for text/images/etc. They don’t make much sense for code though. A more code-specific license applies better in those cases. » Posted By Otto On April 3, 2012 @ 11:38 AM Good Or Bad? Infinite Scrolling Infinite scroll usually annoys me more than helps me navigate. It can be done right, but it usually isn’t. » Posted By Otto On March 30, 2012 @ 11:59 AM Phoning Home To Plugin Authors Note: *In my opinion*, they’re not “phoning home”. Information like PHP and MySQL version is indeed being sent back as part of the core update call, but the information is necessary information to get the proper core update response. Similarly, plugin and theme api checks send information like the plugin and theme headers, in order for the api code to be able to find the right plugins and themes to check updates for. It is perfectly reasonable for other people to see these API calls differently and say that this is “phoning home”, and I can understand their point of view. For this reason, plugins exist to disable those update checks if somebody wants to do so. » Posted By Otto On February 16, 2012 @ 1:37 PM Jeff Starr On Smarter Slugs In WordPress To the best of my knowledge, this doesn’t happen at all. Published post slugs don’t get altered automatically by any process. Now, you might see this behavior for *drafts*, because a draft isn’t published yet and hasn’t had its slug finalized. But when a post is published, the slug is saved as part of the post in the post_name column, and it doesn’t get altered unless you manually alter it. I just ran a quick test and published test-post and test-post-2 (both titles were “test post”). Deleting the first test-post didn’t alter the slug of the second one. Nor should it, I’d think. » Posted By Otto On January 25, 2012 @ 3:30 PM WordPress Ink Does Not Equal WordPress Cult @Dre Armeda – Hey, email me a high res pic for the .org page: http://wordpress.org/about/fanart/ » Posted By Otto On December 28, 2011 @ 2:56 PM WordPress Optimization Guide By Dreamhost @John – It’s not that complicated, really. My nginx config basically looks like this: The first one handles the silly /files/ thing in multi-site (which I’m planning on eliminating soon). The second is the main WP rule. For W3 Total Caches nginx support, it writes an nginx.conf into the WP root directory. So I just symlinked it to the right place for my own nginx config directory. For the W3 settings, I basically turned on XCache support in my dreamhost config panel, then used it everywhere in the W3 settings. Then I enabled the Page Cache, Object Cache, and Browser Cache modules. All three are set to use the XCache to hold their data, so the cached info is stored in RAM, basically. The Page Cache does whole-page caching, and is nice and fast for repeated queries to the same pages, for logged in or anon users. The Object Cache does object caching, and causes my admin section to be nice and speedy, since things like posts and such are pulled from memory instead of the database. The Browser Cache basically just sets the proper expire headers on everything, thus images and such don’t have to be redownloaded all the time. I don’t use the other bits of W3 mostly because they’re unnecessary for my setup. » Posted By Otto On December 13, 2011 @ 10:45 AM Mostly, that page is talking about how to use WP-Super-Cache. That works quite well on their systems using fcgi, mostly because super-cache serves static pages, which never have to spawn PHP processes. On my Dreamhost VPS, I switched to nginx instead, and am using W3 Total Cache to do memory based caching with XCache. This seems to work quite well, although I don’t think nginx is quite as stable as Apache on their VPS configuration. This gives me very fast PHP processes, low numbers of SQL queries thanks to object caching, and full page memory caching. It does take a tad more CPU, and a fair amount of memory, but it seems to chug along just fine. nginx is a beast at statically served files, images and such load up quite fast. Only disadvantage is that page generation is still dynamic and requires CPU, but frankly I prefer it that way. Gives me more flexibility, even if it is a bit slower. » Posted By Otto On December 8, 2011 @ 3:06 PM Removing The Browser Nag Bar In WordPress @Kevinjohn Gallagher – Your blog post rant there, while entertaining, misses some of the point. IE6 and IE7 are actually insecure. There are known security issues that can happen because somebody is using IE6 and IE7. This is why they are being deprecated. Even Microsoft wants people to stop using IE6. Other points such as the problems with browser detection and so on are well-taken, however there are still fundamental underlying problems. Some older browsers really are actually insecure. We know this. It has been demonstrated. This is one of the reasons IE6 support was dropped from the WordPress admin entirely, and also why IE7 support is slated to be dropped as well (not in 3.3, it didn’t make that.. maybe in 3.4 or 3.5). Windows XP is 10 years old, and will be at its end-of-life in a bit over 2 years from now. It’s time to upgrade your OS too. I realize that you don’t like the whole idea of upgrading, but it’s a fundamental fact in computing that isn’t going to go away just because you and your clients don’t like doing it. Adapt. Or die. Either way is fine. » Posted By Otto On December 6, 2011 @ 3:51 PM Or you could just click the Dismiss link. Pretty sure that works. » Posted By Otto On December 6, 2011 @ 3:43 PM Cleaning Up The “Cannot Redeclare Mess” From reading some of the comments on that thread, it appears to be a generic attack aimed at entire servers instead of a WordPress specific attack. Notice the mention by some people of the code being in all index.php files? That indicates a process running on the server searching for index.php files and automatically appending code to them, regardless of whether it’s WP or not. One guy found a copy of wunderbar emporium on his site as well. Wunderbar emporium is one possible name for a root privilege escalation trick on older Linux kernels (it was also called sock_sendpage null pointer dereferencing, but that name isn’t very interesting). » Posted By Otto On November 29, 2011 @ 5:30 PM Tips On Creating A Good Plugin Readme.txt File Also, some plugins that work with Changelogs in these files (the excellent Changelogger, for one), expect latest-first type of information in order to function properly. » Posted By Otto On November 29, 2011 @ 5:52 PM Upgrading And Backwards Compatibility For Plugins @Kevinjohn Gallagher – Not to be glib or anything, but if you users need “training material” to use WordPress, then it is my considered opinion that they shouldn’t be doing things like “touching computers” or “looking at screens” in the first place. I grant you that other people’s needs are different and varied. But seriously, you’re discussing the kind of projects that I used to work on. Major systems, years of development, multi-year timelines, six-month long roll-out plans, etc. I’ve been there, I’ve done that. I quit doing that specifically because that kind of crazy ass crap is not necessary in the modern world (or for the modern web). Anything that takes longer than a month to implement is rarely worth the trouble, nowadays, because the situation in a month has already changed. In other words, what you’re describing sounds archaic and backward to me, and no, I wouldn’t do it. I’d refuse such jobs at this point. Companies that can’t update their processes and innovate with the rest of the world can just go and die, AFAIC. I grant you that mine is often a minority viewpoint. Sometimes it’s a minority of one. ;) » Posted By Otto On December 1, 2011 @ 2:56 PM Wait, so you’re releasing code that won’t work with the CURRENT version of WordPress? Yes. And you’re doing it intentionally to force people who are happy with THEIR platform to use a system YOU want them to use? No. You’re misunderstanding my motivations in releasing code in general, and plugins in specific, I think. I don’t write code for my users, I write code for me. I write code because I’m using it and because I find it interesting. I’m a coder, therefore I write code. I release code because the code might help somebody else too, and it’s nice to get feedback on ways to improve the code. I’m not all-knowing, and by releasing code and letting other people use and criticize and modify and improve it, I get the benefit of their point of view and their expertise as well. I can use that to create better code for me to use too. Now, I released SGC because I’d been writing it and using it and many people have asked me for a copy when they saw it live on my site. It’s a preview release (0.1), not fully functional or complete. It works with WordPress 3.3 beta 4, because that’s what I’m actually running. (I always run trunk, everywhere. IMO, stability is overrated. Most of them I manually update to nightly builds, some I have automatically update via SVN every so often.) I’m not trying to push an agenda here. if you don’t want to use the plugin, then don’t. I don’t care if anybody at all uses my plugins, because I’m really writing them for me and me alone. The fact that many other people do use and like them is a happy outcome, but not the end-goal. I mean, they’re free after all. It’s not like they’re paying my mortgage. » Posted By Otto On November 30, 2011 @ 3:30 PM @Milan Petrovic – Why is that not a solution? We are now cutting out themes and plugins that are older than 2 years from the WordPress.org directories automatically. Most of the feedback we’ve gotten on the idea has been along the lines of “2 years seems like it’s too long”. People not upgrading their code is a problem to be solved, not a data point that you should be considering in order to adjust your development practices. If somebody is running older versions, then they are doing-it-wrong and you need to encourage or help them to fix this issue. » Posted By Otto On November 29, 2011 @ 6:38 AM Don’t leave the users out to dry, just tell them to upgrade their site. IMO, plugin and theme authors providing backward compatibility is one of the major reasons that people are not updating their sites. I practice what I preach in this respect, BTW. The next version of Simple Facebook Connect will require WordPress 3.3. Backward compatibility will not be an option. The Simple Google Connect plugin I released today also requires 3.3 (beta works fine). » Posted By Otto On November 28, 2011 @ 7:56 PM Things You Should Know About WordPress 3.3 Have you seen the new welcome screen? Upgrade to trunk once again. It’s nifty. :) » Posted By Otto On November 29, 2011 @ 6:42 AM Naughty Plugins Caught And Removed From Repository @Baron – When a plugin is pulled for a security exploit, like AdRotate was, there is a specific sequence of events that is supposed to take place. Now, it seems that the developers of that plugin aren’t really paying too much attention to their emails. They were emailed, at their email address attached to the username in WordPress.org, which owns their plugin. They either did not receive the email or chose to not respond to it. There is no reasonable case in which somebody would need to post to the forums, as they claim, in order to figure out who to reply to. They were emailed when the plugin was closed. If they didn’t get it, then maybe they should update the email address on their WordPress.org user account to a valid email address to ensure they stay informed. Also note that this is not the first time they’ve been through this dance; they have had security issues before and they should have figured it out by now. » Posted By Otto On November 29, 2011 @ 6:53 AM WordPress.com Blogs To Get More Advertising That’s a total misquote. I saw him say this on the livestream. And somebody wherever you got that from, cut some bits out of his quote there and rearranged it in the wrong order. When he was on stage, he said something like “last year, I said here that WordPress ran 7% of the internet. This year, it is up to 15%, and 22% of all new domains in the US.” In that case, he was referring to WordPress as a whole, both .com and .org. » Posted By Otto On October 20, 2011 @ 2:10 PM WordPress Not The Choice For Multinational Search Wait, are you saying that we shouldn’t test software updates to mission critical systems now? If you wait until a “release” before you begin testing, then of course you’re going to have problems. Realistically, you should be under a continuous cycle of testing and development at the same time. For example, why is your “dev” site not running trunk? You’d get at least a month or two head start on any testing and new development for upcoming changes, and by the time release rolled around, you’d be already tested and up and running. All it would take would be a push to the test system, a final check, and you’re ready to roll it out within a day of release. It’s not that testing is bad, it’s that you’re starting to test it too late. IMO, of course. » Posted By Otto On October 13, 2011 @ 2:10 PM Revamping The 404 Page For The Plugin Repository @M.K. Safi – Yeah, I made sure that even though it gives you that nice search, it’s also returning a 404 header there too. Should address the bad links issue. :) » Posted By Otto On October 15, 2011 @ 11:32 AM Hmm. Never noticed that before. Good idea. How about a search? Like… err… this? :) » Posted By Otto On October 12, 2011 @ 4:15 PM Some Not Happy With Flyout Menus @Rev. Voodoo - Basically the menus on IE7 are unusable. The tuck behind everything on the admin page. To be fair, there was consideration for removing IE7 support entirely, but I think that got pushed back a release or two. Nevertheless, that is coming eventually. IE7 is insecure. » Posted By Otto On October 13, 2011 @ 2:19 PM The only thing that makes the flyout menus at all usable is the fact that something like 90% of the actions you most commonly use have been copied into the admin bar, in a context-sensitive manner. In other words, what makes the flyout menus usable is that most of the time you don’t have to use them at all. Sorry, but that’s just bad design, IMO. » Posted By Otto On October 12, 2011 @ 4:28 PMComments Posted By Otto
if (!-e $request_filename) {
rewrite ^/files/(.*)$ /wp-includes/ms-files.php?file=$1 last;
rewrite ^.*$ /index.php last;
}
1. The plugin is de-listed from the repository, to prevent further downloads of an insecure plugin.
2. If the exploit is accidental or not obviously malicious, the developer is notified via email. The email comes from a valid address (plugins at wporg) and can be replied to.
3. The plugin developer presumably fixes the exploit or tells us that it is an invalid exploit, updates the plugin in SVN, and emails back saying so.
4. We check it out, and either provide advice or re-enable the plugin.
«« Back To Stats Page