Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: coding

  • WordPress: EU Compliance

    WordPress: EU Compliance

    ETA: Please check out Trac #19622 – There will be a new way to do this in WP 3.4

    Before I get into this, you do not need to do anything to WordPress to comply with the EU cookie law. The legal whoo-hah is clear: Third party cookies (and cookies which track data across multiple sites) are the only ones they’re talking about. MultiSite installs are, technically, one site, all owned and managed by one person, so it’s fine. Google.com, gmail.com and anything else registered to Google would also be fine internally.

    But if you’re dead set on this…. Let me explain first.

    For WordPress, if someone comments on your blog, cookies are stored on their computer that store three things: name, email and website. Even then, they’re only put in when the user enters then. That would entail implicit agreement to having cookies put on your computer, wouldn’t it? Even if you have no idea what cookies are? That certainly is a problem. People don’t know what cookies are, why they’re on their computers, and what they can do. But is that the responsibility of website owners to educate? Certainly, you can easily add a checkbox to your comment for that says ‘save cookies,’ have it link back to an explanation about what’s going on, and make it required.

    It would be pretty easy to flip WordPress around to not save cookies for non-logged in users.

    First you change your KEYs and SALTS in the wp-config.php (you can get new ones at http://api.wordpress.org/secret-key/1.1/wpmu/salt). This will force all users to log back in.

    Next you change your registration/login page to alert people to the cookies. There are plugins for this, and on BuddyPress you can edit your theme’s template page for registration easily. By having the login/registration page say ‘hey, you’re gonna get cookies if you log in!’ you’re now in compliance with EU law!

    Finally you slap this your header (or functions or a mu-plugin file), to delete cookies on every single page you visit, which will prevent cookies from staying on people’s computer ONLY if they’re not logged in:

    <?php if ( !is_user_logged_in() ) { wp_clear_auth_cookie(); } ?>

    One could go even further, making a check-box to permit cookies or not, though that would be far more complicated to track. This very basic way of making the code you own compliant is enough to get you through the day and keep the enforcers off your back.

  • Learning From Failure

    Learning From Failure

    The term criticality accident is what happens when there’s an increase of nuclear chain reactions.  This lets loose a radiation surge that kills people.  This is what happened at Chernobyl, Three Mile Island, Fukushima, and many other places.   To date, twenty-two criticality accidents have occurred outside nuclear reactors (some resulting in deaths), but thus far, none have resulted in explosions.

    When we look at the death of Louis Slotin, we think ‘God, how did we not know that was dangerous?’  When we regard the Trinity Test, we think ‘How did we not know we were unleashing hell on earth?’  The fact is that we cannot see the future, and we cannot predict how far we we go.  Therefore we certainly cannot see when we are too far gone before, indeed, we have gone too far. You cannot divine and magically know the unknown, though that doesn’t mean we’re in complete ignorance of the possibility.

    There is always a possibility that things can go terribly wrong, in the worst way possible. In a nuclear power plant (NPP), obviously things like a meltdown is up there on the top of the ‘worst outcome’ list. Did the scientists know there was a possibility this could happen? Of course they did. Did they know that it might leak into the ocean, pollute the land, and kill those 50 people who are still working at the plant, and who are all expected to die of radiation poisoning? Again, of course they did.

    Before any NPP is built, they go over the risks and mitigate them as best they can. They review the known risks, and solve as many as possible. But there will be a point where someone will correctly state “We’ve thought up ways to solve every problem we can come up with. Now we need a plan to handle situations where the unexpected arises.” Oh yes, they have a plan for this sort of thing too, but it’s probably really basic.

    I don’t work in NPPs, I work for a bank. We sit around and discuss things like ‘If the city of Chicago is destroyed tomorrow, how would we make sure that everyone can get to their money?’ Given that your money, like mine, is pretty much virtual and stored on computers, we do that via data integrity. Make sure that our data is all safe, secure, and backed up in multiple places. We have multiple data centers across the state, protecting your money. What about the software? It’s written to talk to those data centers. How do we compensate if one of them vanishes? The problem with those meetings, is that people want to know specifics. And I always point out ‘Give me a specific situation example, and I will give you specific steps. But since every situation is different…’ Because the answer to ‘What do we do if our Chicago servers vanish?’ is ‘Route everything to this other location.’ See how that’s really basic?

    The problem with all this is we can only plan for what we can imagine, and we can’t imagine past our abilities. Should we have seen the possibility of someone flying a plane into the World Trade Center? Of course! We should have always thought ‘Hey, this nice big skyscraper sure is an easy target for someone really pissed off!’ But the probability of that happening was so low we didn’t come up with plans for how to handle it. A criticality incident happens at that point when we realize what we should have known all the time, but couldn’t have possibly known because we are not omnipotent. We are not perfect and we cannot know everything.

    In the case of a nuclear power plant, when all hell breaks loose, people die. Even today, we know that the radiation being leaked out is bad for us, for the environment, the water and animals, but we don’t know how bad. We cannot possibly know. We can guess and infer and hypothesize. But we do not know. And the only way to know is to experiment. If that doesn’t scare the pants off you, to realize that all innovation comes from an experiment that could kill us all, well, then you’re probably not aware of the hadron collider and how we all joked about how it would open up a black hole and kill us all.

    Innovation takes risk. It takes huge risks. The people who take the risks, like Louis Slotin, know that things can happen. They know that irradiating themselves to kingdom come ends with a slow and painful death, and not becoming Dr. Manhattan. We won’t become Spider-Man or any sort of godlike superhero. We. Will. Die. And we know it. And we do not stop. We cannot stop. The only way to get better, to make it safer, is to keep trying and keep dying.

    Not to be too heavy handed, but with our code, it’s the same thing. We cannot see where too-far in our code, where danger lies, until it hits us in the face. We will destroy our programs over and over, we will crash our servers, and infuriate our customers, but we will pick up the pieces and learn and make it better the next time. This is human nature, this is human spirit and endeavor. We cannot fear failure, even if it brings death. For most of us, the worst it can bring is being fired, but really that’s not that common. I’ve found that if you step up and accept responsibility for your actions, you get chastised, warned, and you keep your job.

    When everything goes bad, it’s easy to point a finger and blame people. That’s what people do. They complain that the programers suck and didn’t test enough, that the testers didn’t do their job, that everyone is terrible and did this just to piss them off. They rarely stop and go ‘What did I do?’ They rarely say thank you, and they rarely learn from the experience of failure. Thankfully their failures will not end in death. Money loss, certainly, and a great inconvenience to everything in your life, but you learn from this far better than you can learn from anything.

    Learning from extreme failure is not easy. It’s hard to get past that initial moment of absolute terror. It’s harder still to train the end users (clients, readers, whatever) that this is okay. This is normal and it happens to everyone, everywhere, everything. But if we cannot learn from failure, we’ll never have the courage to create again.

    Get messy. Make mistakes.

  • WordPress: Open Comments More Selectively

    WordPress: Open Comments More Selectively

    There are a whole lot of tricks you can do with SQL to enable/disable comments.

    If you want to turn them on for every single page, there’s this:

    UPDATE wp_posts SET comment_status = 'open';

    But me? I don’t like to blanket turn things on! I don’t like to have my pages allow comments, you see, so I use this instead:

    UPDATE wp_posts SET comment_status = 'open' WHERE post_type = 'post';

    I find this preferable than just opening it for everything (most people will tell you to omit the WHERE clause) since if you do that, you open comments for attachments, pages, CPTs and everything. Which I never want.

    But what if you did open comments for everything and now you realized, oh snap!, you want to turn them off on attachment pages? That’s pretty easy:

    UPDATE wp_posts SET comment_status = 'closed' WHERE post_type = 'attachment';

    For more awesome SQL queries, check out Digging into WordPress – Easy Comment Management via SQL or the incredible Andrea’s How to Close Comments Across a MultiSite Network.

  • Limitations on Sortable Columns

    Limitations on Sortable Columns

    As of WordPress 3.1 you can add new columns to admin pages and sort them. You could always add them, but being able to sort the columns is new! This was very much welcome from pretty much everyone who makes extra columns, for whatever reason. As someone who likes them (they make sorting so much easier), I pinged out there to ask how it was done?

    My Twitter friends bailed me on and found these very helpful links:

    These both told you how to add columns to the posts table. But what I wanted to do was add a column to the USERS table. When you see what I wanted to add, I’m sure it’ll be obvious:

    1. Show the DATE someone registered in the users menu
    2. Allow the column to be sortable

    Adding in the date was really painless, but I could not, for the life of me, get it to sort! Small problem. Again, I appealed to Twitter, and bless his little black heart, Otto bailed me out and explained to me why that one could work, but others would not.

    What I learned

    Unless your data in the header is stored in the database, you cannot sort by it. End of story. No further discussion needs to happen. This makes sense, as you cannot sort by dynamically generated content.

    Unlike the wp_posts table, you cannot sort by user generated headers in the User Table because of how it draws from the database. Your plugin would have to write to the wp_users table (making new columns instead of using wp_usermeta which is prefered) and even then, the sortables are hard coded. That one broke my head a little. The sortables in the posts table are pluggable (that is, you can make your own). This just isn’t the same becuase WordPress knows what columns are in wp_users. After all, we add stuff to wp_usermeta. This created a circle of ‘Auuuuugh!’ for me.

    Thankfully, Otto pointed out that since ‘registered’ is listed for MultiSite, you can leverage that on SingleSite and MultiSite (and also explained why my tweaks worked on MultiSite!).

    In the end, I was able to take all that and tweak my “Recently Registered” plugin for WordPress 3.1, and made it look hella cool. If you’re using WordPress MultiSite, you don’t need this at all.

  • WordPress 3.1 and Network Menu

    WordPress 3.1 and Network Menu

    This one’s really fast, but the word should get out there. It’s extremely important if you’ve built a BuddyPress plugin, because the BuddyPress menu has been moved. If you do not do this, your BuddyPress menus will vanish, and you will have very angry users.

    WordPress 3.1 has moved the admin menu for MultiSite. Instead of having a Super Admin menu available on the sidebar of your Admin section all the time, there’s a new link in the header bar for Network Admin. Thats right, it’s its own page! The problem with this is that a lot of plugins aren’t ready for that and because of the move, their admin menu links vanished.

    Thankfully it’s an easy fix!

    The WP Codex Doc on Admin Menus tells us to use “admin_menu” when adding menus. Well, if you want your plugin to show up on the Network Admin page, you have to use “network_admin_menu” instead. (Trac #14435)

    See? I said it was easy.

    add_action( 'network_admin_menu', 'MENU_FUNCTION', ## );

    There’s on catch to this. What if your plugin is for Multisite and NON MultiSite? Honestly I don’t know if this matters, but just to be safe, I would do this:

    if ( is_multisite() ) { 
     add_action( 'network_admin_menu', 'MENU_FUNCTION', ## );
} else {
     add_action( 'admin_menu', 'MENU_FUNCTION', ## );
}

    Or this:

         add_action( 'network_admin_menu', 'MENU_FUNCTION', ## );
     add_action( 'admin_menu', 'MENU_FUNCTION', ## );

    That’s right! If it’s there and not-needed, it does no harm! I’m not 100% certain right now if you need to do this for the non-menu calls people make (like calling a function on admin_menu to check for installation), but I’ve been adding it in to no ill effects. I figure, the BuddyPress core code does it, so it can’t hurt!

  • Make An RSS Powered Email List

    Make An RSS Powered Email List

    Sometimes the problems we have are insanely more complicated than they should be, because our heads get trapped in a space they shouldn’t be. For years, I used FeedBurner to manage my RSS feeds. Then I realized I didn’t care that much, I didn’t need to know who was accessing my feeds, and really the only benefit was that I could put ads in my feeds (which … no one clicked on anyway) and 12 people could subscribe via email. Well, with some research I found that I could put ads in my feeds with some WordPress functions (I’ve since removed them) and I could use Subscribe2 as a plugin to email when I had new posts. Don’t get me wrong, I really like Subscribe2 except I didn’t like the interface. It’s on the back end of WordPress. My site is a BuddyPress site. Everything is on the front end for my users, and I like it that way. It all looks ‘branded.’ The plugin dev was, fairly, under the idea of ‘Works how I want it.’ I thought about forking, but as I looked at the code, I thought that I really didn’t need WordPress to handle this. I needed a way to email an RSS feed to a mailing list. A proper, opt-in, stable, mailing list, that wouldn’t affect my blog while processing.

    I found an answer that can be applied to any site, WordPress or not.

    What?

    The problem:
    I have an RSS feed I want to be able to email to people who don’t like RSS, and I don’t want to use FeedBurner, MailChimp or any external process.

    The solution:

    • Setup a MailMan list for your emails and configure as needed
    • Install and configure rss2email
    • Setup a cron job

    Why?

    Why not use [this product]? When I presented this to people the first thing they said was ‘Just use FeedBurner!’ or ‘Use MailChimp!’ I get that I can use those third-party vendors, but I don’t want to. I like to self-host because then, if things go wrong, I have the ability to do something about it. This is also how I increase my IT toolkit. I have a need, I find a solution. Sometimes I write the code, and sometimes I just master a new tool.

    Why Mailman? Mailman (or properly GNU Mailman) is installed on my server and while it may be old, the current stable version is 2.1.14, and that came out September 2010. It’s still updated, maintained and supported. And it works. I’m familiar with it, I’m comfortable with it, and there’s no reason not to. I did experiment with phpList, which claims to be able to handle RSS feeds as ‘source’ on it’s own. The problem, as my Twitter buddy @JohnPBloch warned me, is it’s not friendly. He said “I don’t care much for phpList. I always felt like the software was working against me instead of with me.” And he’s right. It took 5 minutes of setup for me to gag and delete it.

    Why rss2email? I don’t think RSS is dead. In fact, I still prefer it to email (or Twitter). My unread RSS list (currently run via Google Reader) sits, quietly, patiently, waiting my attention. I don’t get spam or junk feeds, and if I decided to mark all my Fail Blog feeds as read without reading them, no one knows but me. I don’t have to reply to anything, and I can go back to using my email for communication. That said, I know a lot of people who like to get updates in their email, so I have to take that into consideration when running a site. Sometimes, when you make a site, you cater to yourself. Sometimes you cater to your audience.

    Why cron? I’m on Linux. That’s what you do when you want to schedule things.

    How?

    Bear in mind that my details are going to be specific to my situation.

    Mailman is the easiest. You make a mailing list. I wanted an announcement mailing list, so under Privacy options -> Sender Filters I set up that all users were moderated by default and to discard their emails. Then added my email under “List of non-member addresses whose postings should be automatically accepted.” I knew I was going to have emails sent from a specific address, and I didn’t want that address to GET the emails, so by putting it on that list, I don’t have to worry about approving posts. That’s pretty much all the ‘special’ customization I did. If I’d wanted to put a reject to other people’s emails to the list, instead of a discard, I’d have added this “This is an announcement only list. Your post has been rejected.”

    rss2email was the hardest, but only because it was new. The install process is really straightforward. I made very minor tweaks to the config.py file, based on a first run when I realized that my mailing list would strip HTML. I set HTML_EMAIL and USE_CSS_STYLING to 0 to get it all to plain text. I changed my DEFAULT_FROM and OVERRIDE_FROM to ‘pretty’ versions of my domain information. Then I had to customize my SMTP stuff, since it requires authentication and is on a special port (not 25).

    cron was the most surprising. Since I have to run rss2email out of the same folder it’s in (Python…) I wrote a quick shell script called rss2email.sh that has two steps. It changes directory to my install of rss2email and then it calls the command ./r2e run. Then I called it with a twice-daily (0 and 12) cron job with /home/USERNAME/rss2email.sh and it’s done. I’m not going to give you a blow by detail on how to do cron stuff. It’s way too complicated to try and overview here.

    Satisfied?

    Pretty well. I’m still massaging the output a bit. The HTML output of a full RSS entry was weird. After changing my WordPress feed to excerpts, I ended up with some weird lines in my emails:

    This was caused by some old functions I had in my theme to insert ads into my feeds (mentioned above). I took that out, called ./r2e reset to clean out the database, and then re-ran the script. Worked fine! I admit, I had some moments where I didn’t like putting the excerpt in. I use a custom crafted excerpt in every single post on this site as part of my layout, and while I prefer to avoid ‘read more!’ type things in my feeds, I realized my custom excerpts would be ‘good enough’ for anyone who cared. I do wish WordPress would make two feeds, one excerpt and one none, but that’s a job for another day. At least I’ve managed to semi-customize my Mailman digest header (via manually editing masthead.txt).

    After all my testing, I deleted the mailing list and reset everything, did a clean build, and voila! Works like a champ, without putting extra stress on things!