Archive | Web Development

Technologies, techniques and neat stuff on the www

Managing broken links

My WordPress site has thousands of links to other web servers. Inevitably, these links grow old and many get lost. I use the excellent and highly recommended Broken Link Checker for WordPress to scan all the blog posts, and flag the links that aren’t working. It sends me an email each morning. There are many reasons why a link wouldn’t work, and a variety of error messages that can result: the request could time out because the web server is down, the network is having a bad day, or the site is no longer available. The request for the link could be rejected, redirected, of forbidden with a variety of error results, some transient and some permanent. If I think the link is down permanently, I can try to find an archive.org archive of the page (which the plugin helps to find) or remove the links as irretrievably gone.

A broken link displayed visually.

Broken Link

When the plugin discovers a broken link, it wraps the link in an HTML element that allows you to highlight the error in a variety of ways. I’ve chosen a red wavy underline to highlight the broken link, and automatically added the text “(Broken link)” to the link. For links that I’ve reviewed and decided they are not only broken, but gone forever, I use a different highlight: an orange dotted underline followed by “(link removed)”. If the reader floats their mouse over the removed link, it will display a caption showing where the link used to go.

All this magic is performed thanks to the plugin, and a little bit of styling. The plugin allows the author to specify their own styles, and I’ve chosen to use the following CSS to create the effect:

.broken_link, a.broken_link {
    -webkit-text-decoration-line: underline;
    -webkit-text-decoration-color:red;
    -webkit-text-decoration-style: wavy;
    text-decoration-line: underline;
    text-decoration-color:red;
    text-decoration-style: wavy;
}
.broken_link::after, a.broken_link::after {content: ' (link broken)';}

How do you learn to type such gobbledegook? Search the web, view other sites whose styles you like, and do your research. In this case, the text-decoration advanced styles (line, color and style) are fairly recent additions to most browsers. You can check on the appropriateness of using new styles at sites like caniuse.com, which can tell you which browsers and browser versions support the styles you’d like to apply. At the link above, you’ll s

Removed Link

Removed Link

ee the style won’t work in Microsoft’s Internet Explorer and Edge, which are another good reason not to use them. The style is supported in the most recent version of FireFox and Chrome, which is good enough for me. I also recommend looking at the “Usage relative” link on caniuse.com, as that shows what version people are actually using, rather than the latest cutting edge version. In this case, caniuse tells me that Google Chrome and IOS’ Safari work better with the -webkit- prefix, so that’s why the style is repeated with and without the prefix.

(Yes, the text-decoration has a shortened form which combines the color, line and effect in a single shortcut line:

.broken_link, a.broken_link {-webkit-text-decoration: red wavy underline;}

but I prefer the longer form, at least until I’m more familiar with the new styles, and the browser compatibility issues.)

Please stay on the line, as calls are answered in the order in which they are received

Astute fans may have noticed the site seems to be having a little trouble. Yup. The site became non-responsive the morning of 20-Nov-2014, and the usual actions had little effect. There were few clues in the logs nor diagnostics easily pulled from the software. To get up and running quickly, I did the famous “WordPress 5 minute Install” and restored the essential configuration. I’ll be restoring the usual theme, fonts, plugins and assets (pictures, links, videos, etc.) from backups as time allows.

Thank you for your understanding.

Notes from Feb 25th Web Dev Meeting: Brian Cardarella on Ember.js

The Portsmouth Web Dev meetup is hosted at Alpha Loft in Portsmouth. This month there were two meetings: Ember on the 25th and Lightning talks on the 26th. On the 25th was the first, with Brian Cardarella of dockyard.com giving the main presentation on Ember.js.

Brian started with a bit of a history lesson. Ember spun off of SproutCore from Strobe. SproutCore 1.0 suffered from the slow (at the time) JavaScript runtimes and overly-complex UI widgets, resulting in a poor user experience. The 2.0 branch was started and Yehuda Katz (core contributor, Rails, jQuery and more) and Carl ??? and pushed off UI elements to focus on the core and on speed.

The run loop is the core event loop engine of Ember, and code in Ember can enqueue new items onto the loop, which continues to loop as long as there are items to be processed. There is great documentation in the Ember Guides, and a good video overview. Brian suggests that the Ember Starter Kit is just that, a good way to get started, but likely not appropriately robust for a professional application.

Enough background, we jumped into http://ember.jsbin.com/ and Brian commenced live coding in Ember to demonstrate how the Ember application essentially hooks into the body tag of the DOM and can read and write elements from there. He showed how actions could be triggered by observed changes, that setters and getters were required for property manipulation.

Ember has its own form of MVC (doesn’t everything?) where Models are business rules containers, and Controllers are contexts in which your interactions with models occurs, essentially acting as proxies. Views are nearly becoming deprecated as their functionality is being replaced with HTML5 Web Components (there’s currently a polyfill for these called polymer.) Routes are similar to Rails with nesting. URLs can be considered a state manager for an Ember app, so two users see the same thing at the same URL, unlike some other JS frameworks. There is an Ember Inspector for Chrome and FireFox that allows you to dive deep into the View Tree, Routes and Data for debugging. Excellent peer support is available on IRC at emberjs and emberjs-dev.

Brian and Dockyard have built Ember-AppKit-Rails as a gem to create a shared directory for an Ember app and its Rails backend. Note this is Very Beta, Somewhat Experimental and may be abandoned. You have been warned. Brian explained there are not yet any Best Practices worked out, so different attempts have been tried. Side-by-side projects where the two are separate may turn out to be a better design; Brian is looking at Ember AppKit [Update: Deprecated, but URL updated for reference]. Ember is designed to deal with different backends, depending on their API syntax. The one he was using was ActiveModelAdaptor, build to work with Rails.

An excellent question on “Where do you do validation?” And the answer: pretty much everywhere. Brian is the author of ClientSideValidations and has some experience with this. He tried something similar with Ember but points out that the context of the front end and backends can be so different that the validations aren’t necessarily the same.

Brian then proceeded to do a demonstration of an under-development project by Dockyard and even in its early stages, it appeared pretty promising.

Brian recommended downloading Ember, reading through the Guides, and taking some time to learn the components. Promises are a key element to the Ember framework and are worth reviewing; ECMAScript 6 will have promises built in. Handlebars, the templating language, is expected to be replaced by HTMLBars in the next major revision. Best practices and calling conventions (especially error/exception/validation handling) are still up in the air; check out JSONAPI.org for some work on this front.

So, we had an action-packed, fact-filled, acronym-filled session with a lot of good material and an excellent overview of the state of Ember and its promising future. Thanks for Brian for speaking and for Josh Cyr, Alpha Loft proprietor, for hosting!

Broken tag cloud

Broken Tag Cloud

Broken Tag Cloud

I noticed this morning that the tag cloud on my blog’s home page was only three lines long. That’s not right. A little study showed that the three lines were word-wrapping based on spaces within individual tags, and that there was no space between the tags, causing them to run off the right side of the pages, where the overflow was hidden. I poked around a couple of places looking for changes to the code that could have caused this: both the WooTheme’s Canvas theme I’m using and the WooDojo add-on only specify the minimum and maximum font sizes, leaving the default ‘separator’ parameter value. The tag cloud is built up in the wp-includes/category-template.php file, where the default is rather strangely set as “\n” as documented on the WordPress site. Adding an explicit parameter of separator to the Woo elements didn’t seem to have an effect. As a temporary fix to confirm I’m on the right track, I overrode the defaul in the wp-includes file to “&middot” and the word-wrap problem is gone. Next, I’ll see if I can find some other place within the Admin UI and/or the database where the separator is specified and see if I can get it reset properly. Stay tuned.

Blog optimization update: WordPress, CDN, Speed, Caching, Accessibility

Keep Calm and Clear Cache

Keep Calm

I’ve continued to do some research on optimizing the blog responsiveness, and I’m pleased with the results. Anecdotal tests this morning, with no local caching, showed a 2 second load time with a 1.2 second DOMLoaded event. That’s pretty good. Here are a few notes on things I’ve been working on:

  • Google’s PageSpeed Tools offered some helpful insights.
  • Minifying some of the text assets – HTML, CSS, and JavaScript – is working well, though I’d like to be more easily able to toggle this for debuggng.
  • Using the Rackspace CloudFiles caching with WordPress lacks a good automated tool on the WordPress side to keep the cache synced with changes. I’ve been using the SuperCache plugin for local speedups, and it supports a variety of CDNs. The CDN-Sync-Tool plugin is no longer available on the WordPress.org site, and several forks on GitHub all seem to be out of date. It’s unclear, so far, where the problem is. The WP cron jobs are failing. Whether that’s an internal configuration problem, or unsupported calls to an old API, I haven’t worked out yet. Next time I try this, I’ll look at some deeper pilot testing for CDNs with better WordPress support.
  • Inspired by “Why Bother with Accessibilty” by Laura Kalbag, part of the excellent 24ways series, I did some initial accessibility testing. The WAVE Web Accessibility Evaluation Tool tests your site for accessibility, an essential feature these days. Accessibility makes your site more understandable and easier to navigate for all users. Disabilities aren’t someone else’s problems; they are a state we will all pass through at one stage or another.There are a few glitches in my templates that I will work to rectify. A larger problem s the observation that my style choices have lead to a rather low-contrast site.

Notes from Seacoast WordPress Developers Group, 4-Dec-2013

Seven people attended the December meeting of the Seacoast WordPress Developers group, held at the AlphaLoft coworking space in Portsmouth, NH. The main topic was “Best Business Practices,” which was a great topic but, as always, the conversations and netwokring and recommendations that went on around the main topic were also very helpful and informative. Among those tidbits:

  • The Ewww image optimizer can reduce the size of images and speed webpage loading with minimal quality change.
  • Matt Mullenweg delivers an annual “State of the Word” speech with lots of interesting insights.
  • Open question: What topics would YOU like to learn about? The group is about YOU. How can we get YOU to attend?
  • Which SEO are people familiar with? WordPress SEO by Yoast was the most popular mentioned
  • Question on speeding sites, and a recommendation for the P3 Plugin Performance Profiler

On to the main topic: “Best Business Practices” can easily degenerate into a “Client Horror Stories” session. Kudos to organizer Amanda Giles for keeping a tight rein on the discussions and getting us to focus on covering as much as possible. Andy provided a redacted proposal he had written up for a client and we reviewed and discussed it. There was a lot of good back and forth. Andy had some very insightful item in his proposal that made it clear what the client would see at each phase, what items were optional or deferred to a later project phase, and how client decisions could affect the outcome in terms of schedule and cost. This was a great launching point for a lot of discussion on terms, contracts (my stance: pay a lawyer for a few hours to draft a good contract!), how to handle open-ended items like design reviews and never-ending revisions, terms for stock photos and graphics, and so forth. The discussion was very worthwhile and everyone felt they had their questions answered and learned a few new things. What more can you ask for a meeting?

Our next two meetings are scheduled for TUESDAY (not the normal meeting night) January 7th and Wednesday, February 5th. Please consider joining the Meetup group to keep up on the details on upcoming meetings.

New post testing CDN support on WordPress

DSCN1940 So, the Content Distribution Network is in place and several tests indicate it is working well — page loads are much faster, the URLs of the CDN content are re-written properly — but the next question is whether new materials will be automatically added to the CDN. The picture at the left (and yes, this is an excuse to post a cute dog picture, too) should appear with a link to the high-resolution (1.8 Mb) image. On the blog itself, that link should be of the format http://blog.tedroche.com/wp-content/uploads/2003/12/NameOfPicture.jpg, while if the picture is picked up by the CDN synchronization software, it should upload to the CDN and the URL be rewritten to http://static.blog.tedroche.com/etcetera. Let’s try it out and see what happens…

Woah. Success first time. Pretty cool.

Some details on what I’ve got set up: I’m using the Rackspace Cloud Files service as the CDN. I had worked with Rackspace before on some hosting projects, and have a friend working there, so I thought I’d try them out first. It appears that their CDN services are in an early stage and don’t have all of the features of soe of the more mature products. In particular, it appears that the blog software is reponsible for pushing any new or updated content to the CDN. By contrast, the Amazon S3 offering has an ‘origin pull’ feature that will pull content from the original source when it is first requested, and subsequently cache it.

In order to get the contents of my local blog to sync with the CDN, I added the CDN-Sync-Tool plugin. A lot of web searching seemed to indicate I could find this in the WordPress Plugins directory online, but the tool has been pulled from the directory. Apparently, it is undergoing some redevelopment. The version I found was on GitHub under https://github.com/WDGDC/CDN-Sync-Tool and installation was not more complex that downloading the ZIP and unzipping it in the plugins folder. Bear in mind that you should be comfortable with using the command line and have the skills to review the files you are installing on your machine, as there has been no review by the WordPress folks, and the code is currently under development and you may need to deal with bugs, incompatibilities and support problems. So, this isn’t the path I’d recommend for less-technical WordPress developers, and likely isn’t the path I’d recommend for a client looking to put a CDN into production use.

Note that most cache programs and their CDN features are set up in such a way that logged-in users may see a slower site, but more up-to-date, site, and that in order to test caching you’ll need to log out of your WordPress session.

 

rbenv on Fedora 19: for want of a nail,…

… a kingdom was lost.

Fortunately, I don’t have a kingdom at stake. My tale is more like the House That Jack Built. I had to spend a little time building the tools to build the code to build the language upon which I build solutions for clients. And the path was strewn with gotchas, but I persevered. Since I’ll likely need to do it again some day, I’ll record it here in hopes I can retrace my patch, er, path.

I’ve installed Fedora 19 on my main development laptop, replacing an older Mint 12 install that had gotten too old to maintain easily. I’ve spent some time updating and configuring the machine in my spare time. With FireFox already installed, Chromium was an early addition. Thanks to syncing, these browsers retain the history and passwords of the sites I spent all day on. I moved over my ssh keys and configurations and vim configurations and installed git and the basic development setup is ready to go: most of my coding occurs on remote systems. Next came Apache and PHP in order to develop locally. Finally, I started on Ruby and Rails. Here, I took a tangent from past installs and installed rbenv rather than RVM, the Ruby Versions Manager. I have seen problems with RVM and the 2.0 version is coming along slowly. In the meantime, Bundler has come along and solved a number of problems with gems, gemsets and disk clutter, but in a different and incompatible way with RVM. I thought that this was a good opportunity to inform myself of a new tool, should I run across it on a new gig. Also, I had seen a Drew Neil videocast in his VimCasts series recently where he showed some very useful tools, but rbenv was a pre-requisite. Due to the way RVM works, rbenv can’t be installed side-by-side, so I had to remove RVM. No time like the present!

However, there’s a catch. Isn’t there always? Fedora 19 uses a version of OpenSSL which is configured differently than what used to be typical. I am no crypto expert, but I understand they disallowed some form of elliptical curve (EC) encryption. Ruby, as part of its build process, tests for that specific functionality, so builds will break on Fedora 19 (and recent Red Hat, too). There is a fix in the pipeline: https://bugs.ruby-lang.org/projects/ruby-trunk/repository/revisions/41808, which changes the behavior from requiring this specific form of encryption, which wasn’t really required, just a poorly chosen hard-coded test) and instead tests to confirm that there are some algorithms for encryption by iterating through them. So. Now, I knew there was a fix, I just had to figure out how to wedge it into my system. Thank goodness for internet search engines! Here http://philippe.bourgau.net/how-to-install-a-patched-ruby-interpreter-wit/ was a similar enough situation that I could interpret the process for my system, with different version numbers, of course, and a few tweaks. After a few false starts, I had my own custom patched versions of Ruby 2.0 and 1.9 installed a ready to go.

It may not be clear why I didn’t just install the version of Ruby that comes with Fedora 19. At the moment, that version is the same (p247) as the current version, but as a developer, I don’t want to have to count on the distribution to keep their versions up to date in order to have the most recent version on my systems. Since I’ll be deploying systems into production, and therefore exposed to potential attack from the internet, I need to have the ability to build from the latest source code and to apply patches as needed. This provides the best possible security to my clients for this app. I also need to support older versions, so having worked out the recipe for 2.0, I was able to backport the same changes into Ruby 1.9.3 and install that on the system as well. At the moment, I don’t have any need for Ruby 1.8.7, but now that I’ve worked out the build routine, I’m confident I could deploy that if needed.

Notes from Manchester WordPress Meetup, 16-Oct-2013

The Manchester WordPress Meetup met at The Farm restaurant (Elm Street, Manchester) on Wednesday October 16th. Their regular meeting night is the 2nd Monday of the month, which they’ll resume November 11th.) A smaller crowd that usual made it to the event, but it just gave us each more time to talk, get our questions answered, and quiz the speaker.

Craig Fifield (www.craigfifield.com) was the featured speaker, talking about Google Authorship. (A second speaker had an accident and was unable to make it. Best wishes for a speedy recovery!). Google Authorship is a means of tagging your written content on the web and linking it to your Google Plus profile. Craig has a lot of experience in the SEO space, as he’s worked with the web since 1995, “before SEO or Google existed.” Craig was very fired-up about the Google Authorship concept, and showed us how to to link our WordPress posts to our Google Profile. Like many Google processes, it’s a two-way operation: establish a Google Plus profile and point it to the publications you’ve written, and edit the publications and include a link that points back to your profile. While there are several WordPress plugins that claim to support this feature, Google Authorship is still a moving target, and none seem to follow the current guidance.

Craig also emphasized that it’s important to test your setup once you get it in place; it’s not enough to embed the links and assume everything works. He recommended using the Google Structured Data Testing Tool on several of the pages to ensure your author information was showing up correctly on individual articles, but not on streams of articles (front pages, archives, etc.) or places where a byline would be inappropriate (About Me or Contact pages, for example).

We had some time for announcements and Q&A as well. Meetup organizer Jonathan May will be teaching Advanced Topics in WordPress at the Nashua Adult Learning Center. Jeff (missed his last name) spoke about the Fossil Fuel Age Challenge Ecosite Competition: a nonprofit effort to promote sites with a green focus by holding a competition and promoting the ecological movement as well as a bit of self-promotion for the developers. Things are still coming together, but it looks like one WordPress site would be selected at random and the winner would get a dinner with Matt Mullenweg, while a winning Drupal site would get a dinner with Dries. It sounds like good fun, and a good chance to get soem promotion of your authoring skills. More details can be found at EcoEnlighten.com and EcoSiteCompetition.org.

Also mentioned: several upcoming meetings: GNHLUG meets at The Farm on October 22, lots of good meetups like the Web-Developers group and the Seacoast WordPress group at AlphaLoft in Portsmouth. And tickets are getting scarce for WordCamp Boston, held October 25-26-27 — get yours soon!

Thanks to Craig for presenting, Jonathan for organizing the meetup, and all for attending and participating!

Seacoast WordPress notes, October 2, 2013

The October meeting of the Seacoast WordPress Meetup was held on October 2, 2013, at the AlphaLoft coworking space. Thanks to owner Josh for encouraging groups to use the space!

Of course, you never get techies together when they don’t just jump into talking about what they’re up to! We had a question on using Content Delivery Networks (CDNs) to improve responsiveness for an international site. David talked about his experience with CloudFlare. A quick Google showed that there were a number of plugins that claim to offer some CDN functionality, and that initial offers the member had gotten might have been inflated.

David also showed the Dynamik theme add-on to the Genesis theme that generates a set of media queries to support mobile devices.

We started off the more formal meeting with a round of introductions: Amanda, Chris, me, Jim, Laurel, Dylan, David, Andy, Tina, and Tom.

Off we go into questions and comments. One member did some troubleshooting of a plugin-laden site using P3, the plugin performance profiler. Others offered their opinions that excessive plugin use can be the source of a lot of compatibility and/or performance problems.

The main presentation of the evening was from Amanda Giles and the Canvas theme from Woo Themes. Wow! This theme can do a lot, lay out in a number of different ways, and has great administrative functions off the dashboard to make lots and lots of changes from within the interface, and not having to fork off a child theme and mess with the code directly. The Premium theme is $119 for developer version or $99 basic. Both include a year of support and upgrades. The Developer version includes PSD files for designers to customize the theme in PhotoShop. A yearly upgrade is obviously what Woo would like everyone to do (who wouldn’t?) but Amanda indicated it’s okay to stick with the version you buy in perpetuity or until they come out with a compelling feature you want.

The number of features were remarkable. Here are a few I remembered to record: easy file structure, lots of hooks, extensive admin functions, support for short codes. Amanda set up a website for attendees to follow along with the various pages of the dashboard and do a little experimenting. Obviously, the access can’t be made public to the entire internet. See www.canvas.client-look.com. We worked our way through many the Canvas options, for an hour! If you don’t have Photoshop, check out pixLR.com for an online utility that will do many of the basic functions.

Woo Themes also includes “templates” within the theme that allows more complex layouts: Magazine has a full-width slider, followed by full-width article, followed by a grid of articles. Also, a second template, Business, with a different layout.

In the header of the Woo Themes dashboard, “View Theme Documentation” takes you to the WooThemes web pages of documentation, which are extensive!

Amanda reminded us that WordCamp Boston will be happening at the NERD Center October 25-27. Well worth the effort to attend. Seacoast WordPress folks will try to get together for a birds-of-a-feather session or lunch; watch the Meetup group for details.

Powered by WordPress. Designed by Woo Themes

This work by Ted Roche is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States.