WordPress is not delighting me, followup

Followup to my post yesterday about WordPress, me, and insufficient delight.

I mentioned that my editor fonts look crappy. I noticed that as of version 4.6, the dashboard is supposed to take “advantage of the fonts you already have, making it load faster and letting you feel more at home on whatever device you use.” It may be doing that for fonts outside of the HTML editor tab, but for that tab, it isn’t using my chosen monospace font. I mentioned that I could probably fix this with Stylish, and I just did, and life’s a lot better now.

I mentioned that my markdown text is getting converted to HTML, which I really dislike. The WordPress.com account on Twitter kindly replied to tell me that this is a feature, not a bug.

I couldn’t find a mention of this change in any of the past years’ changelogs, and the doc page for WordPress markdown disagrees, but maybe it’s just in need of an update.

I mentioned that the media manager wasn’t surfaced in the new UI, and that that’s how I’d been uploading images to include in my posts. WordPress.com pointed out on Twitter that I can use the Add Media button in the editor…

But, there’s no Add Media button in the HTML tab of the editor, which is where I edit my markdown, which, I guess, will automatically convert at some future point to HTML anyway, so…

However, I realized that I can use the Set Featured Image button in the sidebar to upload an image, copy its URL, uncheck the featured image checkbox, cancel out of the dialog, and then paste that URL into my post, and that works.

Anyway, I let my annual premium subscription auto-renew about a month and a half ago, so I’m out of the refund window, so I’ll probably stick around, although this markdown to HTML autoconvert misfeature is pretty distressing. Worst case scenario, I’m supporting open source software, so there’s that.

WordPress is not delighting me

I’ve switched blog engines from WordPress to Middleman (a static website engine) and back to WordPress, with various other static engine experiments in between.

I switched back to WordPress, on a premium subscription, because WordPress started supporting markdown, which I like, and because WordPress is open source software (with open source comments support), which I also like. What’s more, paying for hosting through Automattic means not having to mess with WordPress updates myself, and means helping to support a legit open source software company, and I’m into both of those, big time.

BUT. I’m not totally delighted with WordPress. It has to do, mostly, with editor issues.

First, fonts in the editor look crappy, and I can’t figure out how to change that. It’s this low-contrast bullshit that you see everywhere these days. I mean, I’m sure I could use something like Stylish to mod the way the fonts in the editor look so that I can actually use it comfortably, but… that shouldn’t be necessary, right?

Fonts are nicer-looking in the “visual” tab, but as I mentioned, I’m writing in markdown. I avoid writing in HTML unless I can’t avoid it. And even clicking into the visual tab tempts the specter of…

Markdown Reverts to HTML.

UGH! I freaking hate when this happens. Here and there, for reasons I don’t understand, and I’ve been too annoyed about the whole thing to patiently test it out, some of the posts I’ve written in markdown transform into HTML:

That’s a screenshot of the revisions feature, that I use to convince myself that I’m not crazy and that I really did write my post in markdown. I can use this feature to revert to before WordPress crappified my text into HTML, but, the revisions feature is only surfaced in the “old” UI, and that old UI is full of nags about using the “new” UI instead.

The new UI is cleaner-looking, but is missing a bunch of stuff, like links to media management, which I need to upload pictures that I want to include in my posts, pictures that I can store in the storage space that I’m paying for as part of my premium subscription. Which brings to mind…

Upsell messages about the business-class service tier. The preview feature used to include little buttons for toggling between web, tablet and mobile site previews, but that screen now includes a fourth button, labelled SEO, and clicking it brings up an ad for the $25 per month business tier of WordPress service.

And of course, customization is a bit of a PITA. WordPress themes are legion, and there isn’t a nice way to filter searches for these by things like theme features supported, so there’s a ton of trial and error involved in finding a theme that’ll work for you.

My big issue has been finding themes with proper support for the “link” post type, and by proper I mean that if I include a link post, I expect the headline to link straight through to the final source, not to a stupid little stub page (I hate it when sites do this) and I want my rss entry to link straight through, too.

The theme I’m using now works this way, but I wish a couple of little things with the site were a bit different, and I know that much is doable via custom CSS, but:

And I’m disheartened to Google for WordPress solutions only to find these sad five year old posts asking similar questions, often unanswered, and when there are answers, they very often involve installing plugins, which you can’t do with hosted WordPress, and which are probably buggy and out of date, anyway.

BUT, whatever, if markdown worked well, and it really ought to, and if the editor got some more love, which… I don’t know, maybe it has gotten love, just not from anyone who actually uses the editor, at least in along with markdown, if these little editing bits were working better, I’d probably be pretty happy, and I imagine I’ll someday beat my CSS demons to figure out the rest.

blogging, control and open source

I’ve been sort of trying to get blogging again on WordPress lately, and as part of that, I’ve been paying more attention to the blogs I’m following using the WordPress Reader function. Recently, on Om Malik’s blog, I saw this item, pointing to the blog of photographer Eric Kim:

Instagram is now like Facebook

I clicked because I’ve been thinking grumbling thoughts lately about Instagram and its Twitter preview hiding ways.

OK, yeah, algorithm hate — it seems that every social network eventually adds features for bubbling up, through the magic of computer science, potentially interesting items you may have missed. These features disrupt the straight chronological feed presentation that many users prize (for themselves or for their followers). I know about these sentiments. I don’t share them — I like the option of “smart” timeline presentation. But, to each their own.

Anyway, I was interested to read, lower down, his suggestion: Start your own blog, and use WordPress.

I agree with this. I too am using WordPress, in part because WordPress works well, and in part because WordPress is open source software, and I’m an open source software loving sort. I was intrigued, further down, to see that all of Kim’s site content was open source:

Awesome! I clicked this link, assuming I’d find a creative commons license, but found instead a pair of essays about Kim’s ideas around open source photography:

OK, that sounds good. But what about licensing? I couldn’t Ctrl-F my way to finding the word “license” anywhere, so I broke down and read a bit more closely. I found this:

I also wanted to announce that I have recently made all of my photos on Flickr available for free as full-resolution downloads.

The terms he described sounded like a creative commons non-commercial license, which I don’t really consider to be open source, but whatever. Interestingly, the license he’s actually using is more permissive than he describes. He’s chosen the Public Domain Mark 1.0 license, which states that, “You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission.”

As for the content on his site, there’s no license, but this chunk of text suggests that he may be talking about something else when he says “open source”:

So, interestingly, he’s at once ceding more control (over his pictures) and less control (over his blog posts) than he seems to intend. Even among open source software enthusiasts, it’s sort of common to downplay/misunderstand/dismiss licensing, and to insist that what really matters is something else: community, process, governance, etc. All of that definitely matters, but we can’t forget about licensing — copyright laws enforce a no-sharing-allowed default setting, so when we set out to collaborate freely, we need to explicitly change that setting, and open source licensing is how that’s done.

Speaking of which — I hadn’t yet put any license information of my own on this blog, which made it ALL RIGHTS RESERVED. I fixed that with a visit to the creative commons license chooser page and some wordpress widget box-fiddling.

Cutting out the Middleman, with WordPress

For the past few years, the only posts I’ve written in this blog have been about this blog, and this post is no different. I make up for it in lack of volume: I’m averaging about one post a year.

Two years ago, I wrote about how I’d finally (almost) gotten my static blog all set up the way I wanted it, complete with self-hosted, open-source commenting functionality. Yay!

One year ago, I dumped some quick notes about how I’d re-homed my blog to Github Pages and wired it up to Github’s Travis CI service such that pushing posts or updates to my blog’s git repo would trigger a build and refresh of my site. Yay!

Of course, I still had some things to figure out, and while I eventually figured out most of it, I wasn’t blogging — I’d think about my blog, and my thoughts would immediately turn to distraction over hosting and customization and maintenance. If I’m actually going to write here, I should try to make the experience as smooth as possible, with fewer non-writing avenues around to distract me.

Middleman Retrospective

A few weeks ago, I was reflecting on my too-static blog, and on my general blog desires, which haven’t really changed since I switched away from WordPress:

(listed in order)

  1. I don’t want to admin a dynamic web app
  2. I don’t want to write/edit post in HTML
  3. I want to use open source software
  4. I want to be able to customize my blog
  5. I want an easy editing/publishing experience
  6. I want to maintain commenting support

With my Middleman-based setup, I had point one nailed. Static HTML FTW. Point two, also nailed. I wrote in either AsciiDoc or Markdown. Point three, nailed.

Point four… not really nailed. Maybe… stapled? Basic customization chores, like figuring out how to add a simple sidebar, took a long time for me to figure out, and each question I answered led to other questions. As I Googled around for answers and fiddled endlessly with CSS, my thoughts often turned to a “retreat” back to WordPress, with all its point-and-clickitude.

Point five, the easy publishing experience, also nailed. The git repo to CI to github pages process I set up worked really well, and the middleman blog-writing UI that Garrett wrote is really awesome.

Point six I had working, using Juvia comments, which, being open source software, kept me in line with point three, but took me out of compliance with point one — I didn’t want to maintain some dynamic, mysql-backed web application just for my blog, and yet, my Juvia comments instance was just that. And, as a bonus, since I first deployed it, the Juvia project has been orphaned.

WordPress: A New Hope

I mentioned above that in dark moments, I felt tempted by a return/retreat to WordPress. I figured I could use the wordpress.com service, which would satisfy my nothing-to-admin, open source, commenting, and publishing ease requirements. A combination of the many nice-looking, built-in WordPress themes and widgets, along with the (paid) option of tweaking theme CSS and whatnot, promised to satisfy my customization needs, as well.

Still, I really didn’t want to write posts in HTML, or have to hand-edit the HTML of the WordPress WYSIWYG editor. I love how markdown can be pasted straight into a email, as plain text, and remain totally readable.

It turns out that about two weeks after I quit using WordPress, the project added a “write in markdown” option to the software. You check a box somewhere, and the write-in-HTML tab in the UI becomes a write-in-markdown tab. So, that’s point two, nailed.

I signed myself up for the $99 premium WordPress subscription, which seems like a lot of money, but comes out to less than my WWE Network and Marvel Unlimited subscriptions, and goes to a company that creates and supports open source software, so… I’ll give it a year.

Getting rolling again with WordPress was easy. I pointed my domain in the right direction, picked out a theme I liked, sucked in most of my old posts from WP backups, converted the very few new ones, and modified my static posts sitting on github pages to redirect permanently over here.

We’ll see how this return to WordPress, now with markdown support and full SaaSification, affects or does not affect my personal blogging. There’s a non-zero chance I’ll be back in November 2016 to tell you all about my new LiveJournal odyssey.

Run OpenShift Origin from LiveCD, and Make it Stick

The OpenShift Origin LiveCD will have you up and running with the code that backs Red Hat’s PaaS in a flash, but installing the LiveCD to your hard drive requires a few workaround steps.

[UPDATE: Check out wiki-fied, updated version of this howto at the OpenShift Origin community site.]

Today, Red Hat delivered on its pledge to open the source code and development process behind its Platform as a Service offering, OpenShift. To help avoid confusion between the Red Hat-hosted service and the open source project and code base, the project is named OpenShift Origin.

The OpenShift Origin source code is available at github.com/openshift, and software packages for Fedora 16 and RHEL 6 are available for download and installation, as well. At this point, though, the fastest way to get and and running with OpenShift Origin is to download this LiveCD image and fire it up on a VM or spare machine.

The LiveCD will boot you straight into a graphical desktop session, based on Fedora, from which you can create a domain and some sample applications. It couldn’t be much easier to use, but as with most LiveCDs, the environment goes away once you reboot. Also, the LiveCD sets you up to interact with any applications you install through the web browser and terminal window in the LiveCD environment. I prefer to use the browser in my regular desktop environment.

Fedora LiveCDs come with a nifty “install to hard drive” option, but in order to install the OpenShift Origin LiveCD to a drive (whether physical or virtual) a couple workaround steps are currently required:

  1. Download LiveCD and boot a VM with it. The project wiki includes instructions for setting up a VM with VirtualBox. I used KVM and virt-manager on my Fedora 17 desktop.
  2. In the terminal window that pops up once the LiveCD has finished booting, type “su” to become the superuser.
  3. The OpenShift Origin environment requires that NetworkManager be disabled, but the system installer requires NetworkManager. Enable NetworkManager by adding the line “NM_CONTROLLED=yes” (no quotes) to your network adapter’s config file. Assuming your network adapter is named eth0, this command ought to do the trick: “echo NM_CONTROLLED=yes >> /etc/sysconfig/network-scripts/ifcfg-eth0”
  4. Restart the network service: “service network restart”
  5. Start the NetworkManager service: “service NetworkManager start”
  6. Start the installer: “liveinst”
  7. Go through text-based install steps, finally rebooting your VM, and logging in as root.
  8. I’m not positive which firewall ports must be open, so for now I’m just disabling the firewall with: “system-configure-firewall-tui”
  9. Run “ifconfig” to figure out the IP address of your VM, and head out to your regular desktop environment to carry out a bit more configuration, and to start using your mini me PaaS installation.
  10. If you’re interested enough in OpenShift to be running OpenShift Origin on one of your own machines, I’m assuming that you’ve already tried out the full-sized, Red Hat-hosted OpenShift service. If so, you’ll want to create a new config file to use with your locally-hosted OpenShift instance, otherwise the rhc client will default to talking to the OpenShift servers off in the clouds.  I created a file called express.conf containing two lines: “default_rhlogin=admin” and “libra_server=YOUR_VM_ADDRESS”.
  11. Next, I created a domain on my OpenShift Origin instance, making sure to append the path to my alternate config file: “rhc domain create -n origin –config=/home/jason/Desktop/express.conf”. When prompted for a password, use “admin”.
  12. Now, you’re ready to install an application. I’m partial to WordPress as a demo app (my blog is powered by WordPress+OpenShift) but if you’d like to try a different app, here’s a big list of easily-deployed quickstarts.
  13. Start following the instructions at the WordPress quickstart, making sure to append your alternate config file like so:
    rhc app create -a wordpress -t php-5.3 --config=/home/jason/Desktop/express.conf
  14. Your OpenShift Origin will create the new PHP app, and then time out trying to resolve its DNS name. Since we’re interacting with our PaaS from outside of the LiveCD environment, we lose the LiveCD’s automatic DNS magic, and have to make things resolve properly on our own. I made things resolve properly by adding a line to my /etc/hosts file, associating my VM address with the my appname-domainname at the example.com domain to which the LiveCD defaults:
    192.168.122.147 wordpress-origin.example.com
  15. The DNS time-out message we received in step 14 includes a git clone command for pulling down your skeleton app structure from your PaaS instance. Run it.
  16. We need to give our wordpress app a mysql database to work with. There’s a command for this in the quickstart, to which we’ll again append our alternate config file:
    rhc app cartridge add -a wordpress -c mysql-5.1 --config=/home/jason/Desktop/express.conf
  17. We’re near the end. Next (and these steps are straight out of the WordPress quickstart) we cd into the app directory, hook up to the wordpress example git repo, pull the code down from there, and then push it up into our OpenShift Origin instance:
    cd wordpress
    git remote add upstream -m master git://github.com/openshift/wordpress-example.git
    git pull -s recursive -X theirs upstream master
    git push
  18. If you’re following along with me, you should now have a shiny new WordPress instance available at http://wordpress-origin.example.com, with your default admin user name and password listed in your terminal window following the “git push.”

So that’s it. You have your very own PaaS instance running on a local VM that won’t go away between reboots.

The open sourcing of OpenShift is a big deal, but the best PaaS is the one you don’t have to operate yourself. That’s why, as the only current downstream project implementing OpenShift Origin, Red Hat’s OpenShift service remains the best place for people to get acquainted with the project. Here’s hoping that not too much time passes before a bunch of rival implementations hit the scene to give Red Hat a run for its money!