Year: 2012

Art History of Plugins

This post is dedicated to Lisa Sabin Wilson, who donated to help me get to WCSF. Lisa is to documentation what I am to the forums, and encourages me to write better (though she probably didn’t know that).

Quite often people suggest that we ‘weigh’ the usefulness of plugins and themes in the WordPress repository differently. Some want to use star ratings, other popularity, and others compatibility of WordPress Versions.

Invariably, if I get roped into these discussions, I say ‘None of it maters more than the rest.’ And people always argue that their chosen method is the best. No one has ever succeeded in convincing me they’re right and, I’m pretty sure, no one ever will.

The reason I’m so sure about that is the same reason we don’t just buy cars based on the tire size, or a house based on a bathroom. It’s the reason we research and compare, study and inspect, and ask our friends. It’s because we know to look at the big picture.

Let’s look at A Sunday Afternoon on the Island of La Grande Jatte. From afar, it’s simple. A painting of people on the island. But if you walk up to the painting (it lives in Chicago, I love visiting it) you’ll see Seurat painted entirely by dots! As you step in and out, the painting changes and your perspective and understanding of the work as a whole changes. You cannot simply say ‘There is blue paint.’ and make your final decision that this painting will look nice against a blue wall. You have to consider how it will look up close, far away, and will it be better to blend or contrast. Seurat liked the contrast, which is why it has a brown border and a white frame.

The small moments, those dots, make up the whole of the piece and you have to consider everything that went into it, if you want to understand the painting. Anyone can look at if from afar and say ‘Yeah, nice.’ But when you start looking at the work, and the layers of meaning, you see things differently. With art, that’s the point. Sometimes a painting is just a painting, and sometimes a story is just a story, but more often than not, the ‘deeper meaning’ your teachers were after you to get from a story is simple: Look at the whole story. Look at how each character’s actions become a part of the whole.

This relates, directly, to understanding plugins. At heart the question people are asking is simple: How do I know which plugin is the best to use for this situation?

You can’t just take one and say ‘This is compatible with 3.4, therefore it is superior!’ I wish you could, my life would be easier. Instead, you must learn how to review plugins critically. Don’t throw your hands in the air, you don’t need to know code to do this. You do need to know what you want, and you need to read and pay attention, but at this point, if you’re still reading this blog post, you know how to do those.

The secret magic, which I talk about in WordPress Multisite 110 (Chapter 6: Security, Plugins, pg 36), is to review all components of a plugin’s information. You have to look at how all the little dots make up the whole picture — that’s why we talked about Seurat — and use those to understand how likely a plugin is to be safe to use.

Who wrote it? If I see a plugin written by someone I’m familiar with, I’m more inclined to trust their work. I already know how to get in touch with the developer if something goes wrong, and we have a rapport. Second to that is if they work on WordPress core. If they have commit access, I trust them (even Otto, who’s broken the site before). If they’re a regular contributor, it’s much the same. However this is not ‘common’ information. It’s easy to find, but it’s not something everyone knows off the top of their head. You can quickly search trac for their user name. I find it easier to limit the search by changesets, so here’s a search for wpmuguru’s credits in changesets. Yeah, looks like a trustworthy fellow!

What does their website look like? In cases where the developer doesn’t have any core contribs, move on to look at their website. Is it the generic version of WordPress with barely any content? Is it a Geocities flashback? You know crappy websites when you see them, and a crappy website for a developer warns me that they don’t use WordPress the way I do. Little to no content implies they’re not writing posts, and if they aren’t writing posts, how do they keep up with the look and feel dynamic of WordPress?

Is it well documented? Documentation is king. A plugin that is poorly documented, with poor spelling and grammar (regardless of language), and no screenshots makes me Spock the eyebrow. Not every plugin needs a screenshot, but a plugin should have the basic information included on that page. I’ve started copying my readme content into the contextual help in my plugins, for extra documentation levels. The point is, if the documentation is sparse, either the plugin is really simple, or you’re going to have a bad time of it when you have a problem. Developers, document. It will save you a lot of time.

How often is it updated? This is where we start to get weird. The simpler a plugin, the less it needs to be updated. Impostercide has barely changed since WP 2.5. I do update it about once a year, to change the versions, or add internationalization/help screens, etc. The bones of the code have not changed since 2005, and the original version still works just fine. Not every plugin should be updated every month. Now a more complicated plugin, I’d actually like to see it updated more often, with smaller changes. Don’t change it all at once, after all. Review the Changelog (if they don’t have one, it’s not well documented). See what’s being changed.

What problems have people had? Recently the Andy/Otto team made it easier to see the forum posts associated with a plugin, which means it’s easier for you to see how active a developer is with support, and how problematic the plugin is. Many of these issues are user-based (i.e. they’re not sure how to use a plugin), but sometimes they’re actually bugs. Check how many problems have people had, and if they are resolved. This example is a great sign:

What’s in the Compatibility Matrix? This is a very complicated thing, but it’s also very telling. Knowing how many people have reported a plugin works or doesn’t work, and getting an average, can help you. Sometimes you have to go back and forth, checking various plugin versions to WordPress releases, to get the whole picture, though, so it can time time to understand what’s going on.

What Else? Only now do I take a look at things like downloads, what the author says it’s compatible to, when it was last updated, and what the stars are. Why? Because unless an author has written ‘This plugin will not work on WordPress 3.4!’ in the readme, there’s a darn good chance it’s just fine and they didn’t bother to update. And that pisses off a lot of people.

Look. There’s no feasible way to force the developers to update their plugin documentation right now, and even if we did, there’s no way to assure they got it right! People make mistakes, which is why we have to learn to use our brains and think about what we want to do before we act. Yes, it’s work. As I’ve said many times, running a website is work. It’s always going to be, so at least try to work smarter.

I didn’t touch on code reviews at all, but what tips and tricks do you use when you’re collecting all the dots and evaluating a plugin for use?

9 July, 2012
Plugin Licenses, Upsells, and Add-ons
This post is dedicated to WPEngine, who donated to help me get to WCSF. While I don’t use them, I think that if you’ve outgrown WordPress.com and aren’t quite ready to host everything yourself, but you still want the plugins and themes, then you should check these guys out. They aren’t cheap, but then again, I firmly believe in paying for what’s important.

Read the comments before you comment. Otto haz the smartz.

One of the many rules of WordPress.org hosted plugins is you can’t phone home. Actually you can, and the rule really is ‘Don’t phone home without a damn good reason.’ To use Akismet as an example, it phones home with information to help verify who posted on your site, and are they a damn dirty spammer. That’s a damn good reason. But phoning home to check “Did Bob pay for a license?” is not. That’s considered abuse of the “serviceware” guideline, and essentially making an API just to make sure a license is okay isn’t okay. Now making money on your plugins is an awesome thing. But when your code is open source and anyone can see it, how do you keep people honest?

To get down to brass tacks, I’m going to take a little jounrey the wrong way, before I get to some suggestions on how you can provide ‘free’ and ‘pay’ versions of a plugin on the WordPress repository, and not cause any guideline issues.

Let’s start out with the most common way people restrict you: A license key. If you put in a plain license key check like this, it’s easy to crack:
```
if ( $license == "yes" ) { // Licensed! }
```
Okay, you say, I want to encrypt things so that I tell someone ‘your license is ipstenuisreallyneatsheismadeofturtlemeat’ but when I look at my code, it shows ‘774ffc4efce8da294dff77f35f75df98‘ instead (that’s md5(ipstenuisreallyneatsheismadeofturtlemeat) as it happens). Wait. We can’t encrpyt code. Or rather, we can’t include encrypted code in a plugin, it’s against the no-obfuscation rule. We’d want to decrypt that instead. So I give you the code string instead and run it this way instead (Just pretend that $options['license'] is a site option.):
```
if ( md5(ipstenuisreallyneatsheismadeofturtlemeat) == $options['license'] ) { // Licensed! }
```
But then I have the problem of anyone can just look and see what’s going on again. You could go the extra step like putting ipstenuisreallyneatsheismadeofturtlemeat in a file and then pull off something like this:
```
$md5file = file_get_contents("md5file.txt");
if (md5_file("test.txt") == $options['license'] )
```
Is this easily decrypted? Yes. Is this easily circumvented by editing the code and removing the if? Again, yes. In fact the only way to really do this would be to use an API on your server to check the validity of the license (which you can’t do if you want to be hosted on WordPress.org anyway – no APIs just to check licenses), and even then I can strip mine your plugin and remove all checks like that. So why bother? Because you want to make a living on your code, and that’s certainly a fair-go! But as Otto rightly says, we can’t stop piracy, so why are we trying? DRM doesn’t work, and reverse engineering hasn’t proven sustainable. Maybe we’re building the wrong mousetrap.

If we throw the code solutions out the window, because we know they won’t work, where are we left? The next most common thing I see is people offering two plugins. A free, totally open GPL one on the WordPress repository and then a version behind a pay-wall that you would ‘replace’ that free one with. For example, I have a Rickroll plugin, and let’s say I wanted to make a Rickroll Pro version that let you change the video to anything you want, just put in the YouTube URL. I would have a settings page on my free version that pretty much says “Hi, if you want to change the video, visit halfelf.org/plugins/rickroll-pro/ to download.” And now I have to code Rickroll Pro to check if Rickroll (free) is installed and active, and refuse to activate if so. Furthermore, my users have to be told to delete the free Rickroll.

You know what? That’s a pain in the butt. What if instead I coded a Rickroll Pro add-on. No, I don’t mean ‘add this file to your plugin’ but ‘Install this second plugin, which will add functionality to Rickroll.’

It’s a second plugin, yes, but now I can have Rickroll free look for Rickroll pro. Not active? The settings page (which I would keep in Rickroll free) would tell you ‘Hey, you don’t have Rickroll pro! Install it and get more things!’ or ‘Hi, you have Rickroll pro installed by not active. Don’t you know it’ll never give you up? Activate it and have fun!’

Now the code muscle becomes a question of ‘How do I ensure my dependency checks work?’ First, Scribu wrote an awesome plugin dependency plugin, and the only flaw with it, is you’d have to install a third plugin. We don’t want that here, since yet another plugin is problematic. But looking back, that code grew out of a trac ticket about handling plugin dependencies. Now there’s a nice way to check: is_plugin_active()
```
if (!is_plugin_active('rickroll/rickroll.php')) {
    // do not activate. Provide message why.
}
```
You could go to town with the checks in there. Like if the plugin isn’t active, deactivate the child and so on and so forth. I’m not going to write it all for you (though Otto wrote a lot about it for themes)

Now going back in your parent plugin, you can run the same check:
```
if (!is_plugin_active('rickroll-pro/rickroll.php')) {
    // Rickroll pro isn't active, prompt the user to buy it.
} else {
   // Include rickroll-pro/adminsettings.php so they can use it
}
```
The one last thought I had on this was how to handle pro upgrades. Since I don’t like to upgrade a plugin a lot unless I have to, I’d make it an ‘upgrade both’. In Rickroll Pro I’d set a version constant, and then in that check to see if it’s active call, reference that version. So Rickroll, after verifying Rickroll Pro is active, would come back and say ‘My current supported version of Rickroll Pro is 1.5 and the constant is set to 1.0. You should upgrade!’ Then every time I write a new version of Rickroll Pro, I’d update Rickroll to point to the new version, and when they upgrade from WP, they would get notified about Rickroll Pro needing an update too.

Probably not the most efficient or effective way about it, but the other option is a self hosted plugin update API.

Bear in mind, because of GPL, all these hoops and ladders can be circumvented. Your plugin can and will be taken away for free. Don’t fight the pirates with registration circuses, and limit the weight of your code by selling the right thing. It’s a strange idea to think that giving your code away for free will help you earn money, but at the very least, not fighting against the pirates will give you time to write better, more secure, code. And that certainly will earn you more money. Then sell your support, because that time is money.
5 July, 2012
Highway To Plugin Danger Zone
This post is dedicated to Mark Jaquith, who donated to help me get to WCSF. Thank you, Mark!

There’s nothing wrong with using someone else’s code. All of us do it. That’s how we make something new: by building off the old. And we all build code that relies on someone else, even when we write operating systems. Everything is interdependent, and that’s okay. The problem with relying on someone else’s code, is that you’re open to their vulnerabilities.

Recently there was a kerfluffle about TimThumb, where the community came together and made a script, used by many themes and plugins, better and safer. This was an awesome moment, where we saw disparate strangers overcome FUD and live up to the dreams of Open Source.

In more recent days, there have been a lot of problems with the Uploadify script, to the point that Sucuri wonders if it’s the new TimThumb when it comes to overuse and vulnerability. Unlike TimThumb, Uploadify isn’t actually insecure due to a bug, but the design of how it works is insecure. Yes, it’s insecure by design. Uploadify allows easy multi-file uploads to your site, but it does it without integration with any user verification, so basically anyone who knows where the file is can upload anything they want to your site.

Uploadify offers some security suggestions, which encourages you to use the right folder permissions, keep the file outside of your public_html, and use SSL. The problem there is you’re still not checking to make sure that the code is only accessed by the right people. This isn’t a flaw in Uploadify. It’s a flexible product that can be used with anything, so they don’t want to lock it down to just WordPress, Drupal, Joomla, or whatever. This is, alas, the reason it’s so dangerous. Anyone can hook into it, if you don’t make it secure enough.

Now. A handful of WordPress plugins have been closed due to uploadify exploit potential (between 10 and 20). Not a lot, when you think about it. That’s because, perhaps surprisingly, not as many people are using it as you’d think. In part, this is from WordPress’s shift to plupload in WordPress 3.3, which allows you to hook into it in themes and plugins. By the way, I recommend you use plupload, because if you’re going to rely on third party code, it should be the one that comes with WordPress core.

The point is not to not use third party code, however, but to use it wisely and to use it safely. It’s your responsibility as a developer to make sure your plugin is secure, and to know what it does. If you don’t understand how someone else’s code works, don’t use it in your plugin, because by using it, you are now responsible for updating it, securing it and keeping it safe. How can you do it if you don’t get it? Furthermore its your responsibility to educate your users as to what a plugin does and how you’ve secured it. This is open source code, the bad guys can already peek in and see what’s up. If they know, then you owe it to the users to arm them with education.

The weakest link in the security chain is the education of the end users. The servers, we hope, know what the heck they’re doing. Ditto the software writers. But the users, they’re often the new guy, the one who doesn’t know what’s what yet, and they trust you. They trust you do your best. Note, I am not saying they trust you to be perfect. Anyone who expects perfection is ridiculous. We all desire it, of course, but you cannot expect it unless you yourself can deliver it. Can you? I thought not.

Alright then so what can you do to protect uploadify and similar scripts? First, lock it so it’s only accessible from the WordPress dashboard panels. If you can only get to it via WP, then you’ve locked yourself so no non-logged in users can access the tool. Then if you slap this code into the top of your file, no one can access it directly:
```
if ( ! defined( 'ABSPATH' ) ){ die( 'Direct access not permitted.' ); }
```
Next we should look into how we check for the user. Can any member of your site upload? Probably not. So let’s use capabilities and roles to lock it all down and make sure only the right users have access. We can use two simple lines to verify the user is logged in, and has the right capabilities to upload. The ‘manage_options’ cap is for Administrators, so loosen it up as you need:
```
if ( ! current_user_can('manage_options') )
die( 'Not allowed to upload.' );
```
You can hook an upload handler up as an AJAX handler via WP’s admin-ajax.php, per AJAX in plugins. If you need a non-AJAX handler, you can handle form submissions on your plugin admin pages. Going through WP gets you authentication and capabilities checking, and easy usage of nonces (see wp_create_nonce() and related links at the bottom of that page for more info).

There are of course more ways to secure things. There are nonces and AJAX, as well as using WordPress’s image tools to help double check if a file really is an image. After all, not everyone can use .htaccess, and some servers are silly enough to let you run a php file with a jpg extension.

But all that really only works if you want to restrict your uploads to members of your site. What if you want to let anyone upload an image? Honestly, you should re-think that. You are not imagur or imageshack. They have layers of server protections which you don’t, and they have levels of checks and balances in software written specifically for image uploads and protections. You don’t. They are a tool specifically for the job of images. WordPress is not. Do you see where I’m going? Do you really need to allow images be uploaded to your site? I bet you don’t.

Shortly after TimThumb was exploited, it was yanked from the theme repository. Since WordPress 3.3 no theme can contain TimThumb. From what I can gather, part of the reason is that code like that should be a plugin, not a theme. But personally, I think that both TimThumb and Uploadify should have official plugins (supported by the original/current developers), and anyone who wants to use that code can hook into those plugins. Then, if there’s an exploit, it’s one plugin to fix and not a couple hundred.

Of course there are as many flaws with that as with any other approach. If the original devs don’t want to support a plugin for WordPress or any other platform, the users would be SOL.
2 July, 2012
Listen to the Aftertaste
On Wednesday, the guys at WPCandy have a podcast, WP Late Night, where they talk about WordPress. After the show they have the Aftertaste. And this week I ended up on the Aftertaste.

Basically Dre noticed I was on IRC (a rarity for me) and asked if I wanted to join them. I thought about it, hauled my laptop into my office and chatted away for an hourish. I’m rarely home and un-busy on a Wednesday, so it’s a treat for me to listen live (instead of at work or on my iPad after the fact).

Aftertaste #25: After WP Late Night 15 (with Ipstenu!)

I’m at the 52 minute mark or so, but the whole after show is 2 hours and change.

Mostly I talked about support, WordPress, a bit about me, and … Honestly I haven’t listened in great detail. My wife says I started quiet and got louder, and others have said I don’t sound like a twelve year old girl, so that’s something.

At the very least, you’ll hear me pronounce my own name.

Amusing things you will learn:
1. Why I can’t rent a car
2. Where I work (but not by name)
3. What WordCamps I’ll be at
4. My citizenship
5. My sense of humor is exactly the same as it is online
I admit to be tickled pink that people think I must be calm and patient with all the repetitive questions you get in the forums. I’m not, they just can see my rolling eyes. I have a sardonic sense of humor, though, so I put up with it. I just vent elsewhere.

Oh and the ‘book I wrote’ mention was, indeed, about WordPress Multisite 101 (and it’s followup, WordPress Multisite 110) so feel free to link people to them.

Fun thing that didn’t get mentioned, yes, I’ll be at WordCamp Chicago. I have a ticket to WC San Francisco, and the vacation days, I just have to sort out the travel stuff and hotels, because I can’t rent cars, and stuff is expensive.

As an added bonus, here’s the last time I did anything audio-esque.
29 June, 2012
DoS/DDoS and You

To a lot of people, you say ‘DoS’ and they think MS DOS, that old command line tool we used to control Windows.

DoS stands for denial-of-service attack and DDoS is distributed denial-of-service attack. It’s a fancy way of saying ‘Someone’s hitting my server with a hammer so hard, it can’t get up.’ Sometimes you can cause an accidental DoS, like by embedding an image from your server into a public Google Spreadsheet.(Which would have happened to poor Panos when he self-attacked.) And sometimes other people will do it to you by hotlinking your images.(Which is why we block that, children.) Even the scanning people have done for TimThumb can look like an attack.

Some people like to say that this sort of attack is new, that the Internet used to be good and kind and safe. In the 90s, I remember clearly accidental DoS attacks happening when a site was so popular, having over 500 people log into it at once would crash it. And once it was learned that this happened on accident, it was used as a weapon. Even before then, you could demon dial a number over and over again, until it crashed. I probably just showed my age, but the point is we could always take down a site via overwhelming it, it’s just easier to do it now and not get caught. Picture a thousand people all coming and knocking at your door, or ringing your doorbell, over and over and over.

So now that you have a general idea of what a denial of service attack is, what can you do about it? If you’re on shared hosting, not a whole lot. The vast majority of ‘good’ fixes for this sort of thing has to take place on a server level. It’s sort of like trying to prevent your house from flooding when a water main bursts. You can put up sand bags, but until the city turns off the water, or diverts the flow, you’re probably going to lose.

A lot of people suggest blocking by IP address, or using a tool like Bad Behavior to stop the trouble making bots. The problem with this is the troublemakers are still ringing the doorbell. Not as many, perhaps, but quite a lot. I’ve said this many times. IP blocking is a bad idea. Yes, blocking by IP address can work, it’s amazingly powerful, and it’s easily circumvented. The TOR Project is consistently lowering the bar for people to get a new IP even faster than the old days, when I could just re-dial my modem. This is a great thing for groups like Anonymous, and annoying for anyone who has to fight the hidden masses. While I fully support your freedoms, I also retain the right to defend mine, and sometimes that means I have to dig in and sort out how to handle the crazy.

The first thing you can do on Shared Hosting is protect yourself against hotlinking. I don’t know how many times I’ll have to say it for the world to pay attention, but linking directly to images on someone else’s website, unless they specifically say it’s okay, is bad. I firmly feel hotlinking is theft of services (bandwidth) as well. Please don’t do it. Every half-baked host in the world now supports mod_rewrite, so grab Perishable Press’ ultimate anti-hotlinking strategy and protect yourself.

Another useful tool is applying the http:bl (HTTP Blacklist) to your server. That sounds like a lot of work, but the payoff is surprisingly awesome. You see, catching more flies with honey is easy when Project Honey Pot tracks all the naughty people. Naturally there are a few WP plugins for that. In addition, if you just need to punt people who are trying to hack you, I would use the 5G Blacklist 2012 by Perishable Press. Combine that with Bad Behavior and most script kiddies are turned away without you having to fuss.

That may seem a little contradictory, since I don’t advocate blocking IPs. There’s a subtle difference between you running around blocking every IP for every jerk, and using a well supported tool to do so. When you get around to blocking IP ranges, you shouldn’t be trying to block individual people, but the robots.

If you get hit anyway, the thing to do is contact your webhost and start a dialogue. They’ll be as helpful as they can, and if not, may I suggest Liquidweb as an alternative? I pay more because I get great service. A good host will take a look at what’s going on and tweak their servers to help carry the load. A good host will help you tweak what you can. Of course, their DOS service runs about $500 a month and I don’t know about you, but I can’t afford that. The little guy has to survive too. Thankfully the other reason I support Liquidweb is that I, as the little guy, get fantastic support. The point is you need to have a good rapport with your host. It’s like they’re your landlord. Respect them, and they come fix your dishwasher ASAP.

Sadly, at the end of it all, the only thing to do about a DOS attack when you’re on shared hosting is to wait it out. Shared hosting is great for what it is, but if that kind of downtime is cutting into your bottom line, you need to consider moving up to the next level. Remember, if this is something that earns you your living, treat it well! It’s like your car. If you make your living driving, you put money into preventative maintenance, and a VPS (or dedicated server) is very much the same. You can only get out of it what you put into it, so put the effort in to make it secure, or hire someone to do if for you. There’s no shame in hiring a mechanic, after all.

28 June, 2012
Tiny Tiny RSS
Credit: Poorly Drawn Lines
The majority of my ‘I am going to learn this if it kills me!’ lessons come from when I’m just dead frustrated with a product. Today it’s Google Reader.

I like RSS feeds. They work well for me, I like having them sitting there, waiting for me to pay attention. It keeps news out of my email (which is for communication) and makes sure even if I miss a tweet, I see the article later. The world comes to me. This is also a part of my evil ploy to keep myself at Inbox Zero (current status – Inbox has 7 emails at home, 11 at work). I only leave emails in my queue when I know I need to hang on to them for a good reason, and even then I’m likely to save them off line (I use IMAP) to keep anything long term.

For the last few years I’ve been using Google Reader because I check my RSS feeds at work (Windows XP, still) and home (Mac), and it lets me sync between the two. Google Reader remembers what I’ve read, and I don’t have to re-read things. But recently Google screwed me over, hard, with their inability to update feeds in anything resembling realtime. Specifically, all my WordPress.org feeds were days, if not weeks behind, and I couldn’t force them to update! What was going on?

At first I thought it had to do with WP’s recent(ish) server upgrade to nginx, as certainly the problem started around that time, so I asked Otto and Nacin if there was a thing going on. Otto replied that there was, but it was Google. See, Google uses PubSubHubbub, which allows for updates in near-real-time. Sounds cool. If it worked. Now before you say it’s clearly me having the problem, it’s not. I asked around, and everyone who monitors WordPress.org related feeds with Google Reader has agreed: the feeds ain’t in real time anymore.

I switched to another feed reader and, lo and behold, it worked just fine. Well that sucks. Now how can I handle all this? I could use a dedicated feed reader, but then I’m stuck only reading on one computer, which I certainly could do, but it’s 2012, and I like portability. What sort of options am I left with? After two weeks of experimenting and testing with various web-based readers, I decided that Google really was the best of them, and I was depressed. But I wasn’t defeated. I knew, I just knew, that some clever soul felt my pain and wanted to help me out. And I was right.

Enter Tiny Tiny RSS. Tiny Tiny RSS is an open source web-based news feed (RSS/Atom) reader and aggregator, designed to allow you to read news from any location, while feeling as close to a real desktop application as possible.

On the grand scheme of things, it’s easier to set up than RSS2Email (which I use on another account on this server), but due to me being on CentOS, which doesn’t really daemonize well for users, I had to cron job my feed updates at first. I set it at 15 minutes, after I ran it manually a few times to catch up. There are a few ‘quirks’ that aren’t as nice as Google reader. Like I have to manually refresh the back to get the read/unread counts to work right, and even with define('ENABLE_UPDATE_DAEMON', false); set, it keeps telling me that the update daemon is off. Turns out I also had to delete the /lock/update_daemon.lock file.

Meanwhile, I dug further into this and found the pretty easy setup for ‘screen’:
```
$ cd /public_html/tt-rss
$ screen -S updaterss
$ php ./update.php -daemon
```
And detach from the screen with CTRL+A+D shortcut. Now someone mentioned that this will ‘break’ if the server is rebooted, so I left my cron job running just in case. I’m happy with cron, if it comes down to brass knuckles.

I’m happy with this, and it’s only been a couple hours. The actually install process was easy, but this isn’t something I’d suggest if you’re the sort who wants a lot of help and hand holding for an app. I’m monitoring my CPU/memory consumption right now, but it seems pretty minimal, so I’m really pleased I have an alternative I like. My wish list is insanely small:
1. A ‘click to refresh all feeds’ button, instead of relying on cron/command line(I could probably code this myself, just haven’t yet)
2. Auto-refresh of the page resets the read/unread counts correctly
And the ‘fix’ for now for those is cron/cli and refresh the page. So I’ll live, quite happily.

Tiny Tiny RSS lives at http://tt-rss.org but they’re also on GitHub.
25 June, 2012

Year: 2012

Art History of Plugins

Plugin Licenses, Upsells, and Add-ons

Highway To Plugin Danger Zone

Listen to the Aftertaste

DoS/DDoS and You

Tiny Tiny RSS