There are several scenarios that might require your site’s content to be encrypted in your database. Student data, medical records, any kind of financial data - any site owner who is storing this kind of information is going to be very interested in encryption.

I ran into an issue a couple of years ago where a site owner wanted all the node data encrypted (it was an educational site, with student data privacy concerns). While this is certainly possible, it created performance and usability problems that finally made the client decide to ditch the whole idea.

Now a Google Summer of Code project has turned out a Drupal module - Pubkey Encrypt - that simplifies the whole process, to the point where it's purportedly not a usability or performance disaster any more.

And so Drupal 8 gains one more leg up...

https://colan.consulting/blog/user-friendly-encryption-now-drupal-8

We've trained people to be certain for years, and then launch them into a culture and an economy where relying on certainty does us almost no good at all.

http://sethgodin.typepad.com/seths_blog/2016/09/teaching-certainty.html

Palantir announces that the Workbench Moderation subsystem, which was quite a useful contrib module  in D7 and D8.1, will become part of Drupal Core.
Moving Workflow into core removes some obstacles to full functionality, though I must say Workbench worked pretty well before.
If you don't know Workbench, check out its ability to support a complex editorial process, with various levels of access control.

https://www.palantir.net/podcast/secret-sauce-ep-30-state-workbench-drupal-8

Here's a quick take on an old tactic - offering free content in return for contact info. 

http://imagexmedia.com/blog/2016/08/what-are-squeeze-pages-and-how-do-they-work

P.S. there's a Drupal module that makes this a little easier, though it's not hard in any case:
https://www.drupal.org/project/squeeze

"It's far easier to sell someone on a new kind of fruit than it is to get them to eat crickets, regardless of the data you bring to the table."

http://sethgodin.typepad.com/seths_blog/2016/08/pattern-matching-as-a-shortcut-to-growth.html

The basics - and even advanced aspects - of SEO are so ordinary for Drupal site builders that sometimes we forget what an advantage Drupal affords us. While site owners still need to think about content quality, metadata and search terms, creating a high-rankable site is a matter of course for Drupal developers.

Here's a brief look at MediaCurrent's SEO work for a client, which also serves as a simple how-to for site builders focusing on SEO in a Drupal environment.

http://www.mediacurrent.com/blog/drupal-seo-win

Course complete ff3bc01bb1609ae6d0d0c4057c9822d9 Over the last couple of years, I've benefited greatly from many online course offerings. If you're in my business, you'll know how essential it is to try to keep up to date with the latest and greatest.
I'm long since past needing to be one of the cool kids; but some of the new stuff that's come along (I'm looking at you, Angular) has actually vastly improved my ability to get useful work done for clients.

Once in a while, though, it's necessary to pull back from the cutting edge, and wander into a section of the coding world that smells old and musty, and makes your lip curl.

HTML Email is just such a section.

If you've been around since, say, 1998, you'll recognize with a shudder some of the techniques that Email coders have to use every day. Tables, in fact - the rest of us long since gave up using tables for layout of anything but actual tabular data. They're hard to style, and really hard to make responsive. Sadly, they're the only strategy that will survive the preprocessor mangling that many email clients will subject your content to.

There's also the issue of what Email clients will respect which directives. Did you know, for example, that Gmail strips out any "style" links, so that you can't include remote style sheets? You can't even reliably put a bunch of CSS in your Head element. And don't get me started on Outlook, which apparently uses the perfectly atrocious MS Word rendering engine.

Many marketers get around this sort of nonsense by using online email services, especially ones with a design tool attached. Mailchimp is my personal favorite - and not just for its awesome simpatico with Drupal. Others swear by Constant Contact, Lyris, Vertical Response, etc. What these services have in common is that, to a greater or lesser degree, they help tame the beast of HTML email design. (Well, my one client's experience with Lyris isn't all that encouraging, but the others do seem to help).

However many of us still need to understand what's going on under the hood. No cloud service is perfect, and there are enough good clients using bad online email designers that there's still a role for us code monkeys. As usual, we get called when something goes sideways.

That's where Codeschool's new HTML Email course comes in.

As with all of the Codeschool courses, the format is: video lecture, followed by some exercises that you complete in their guided-learning tool. You can download the video to replay later, as well as the PDF of the content; I like to keep the PDF open while doing the exercises just so I don't have to re-watch the whole video to get that one little snippet that I forgot about.

You may choose to skip the intro musical number that Codeschool enjoys putting at the start of every video, but altogether this course adheres to Codeschool's usual high standard of presentation and content.

Who should take this course?
Anyone who's interested in not being embarrassed by spending an entire afternoon fixing up a half-page of HTML that looks like it was written in the last century.

You'll want at least a rudimentary understanding of HTML elements, media queries for Mobile, and CSS style tags. But you'll likely be able to figure it out if you're comfortable with any kind of coding or markup at all.
If not, see Codeschool's other excellent course offerings on those subjects.

MarsEdit3Icon256

For several years, I've been using and recommending the excellent Mars Edit for folks who want to write blog posts offline for later uploading.

There are several reasons for people to want to do this - for one thing you can work on several articles at once, without having to flip between browser tabs. Also the better offline editors have good media management, allowing the user to upload images from the desktop easily, and in some cases even pull from iPhoto, or from previously published stories, without breaking the flow of writing. Even the best WYSIWYG editors that work in-browser can't quite match the ease of use and basic unobtrusiveness of a good offline editor.

One user has also points out that she feels safer having a local copy of her posts available as backup, or in case she wants to pull a bunch of posts together for a story collection or a book.

In any case, offline editors are popular, and Mars Edit is one of the best (Mac only, sorry).

So when I recently updated this site to Drupal 7, I figured everything would Just Work, as they say - silly me. There are some configuration issues on the Drupal side that have kept me busy today - nothing that was Mars Edit's fault. It all comes down to setting up BlogAPI correctly.

Just by way of background: Drupal requires the addition of the BlogAPI module in order to provide a web service that allows remote posting in the manner we're looking for here. BlogAPI will accept POST methods, authenticate the user, parse the provided xml, and create or update the node for you. It will also accept images and put them in the Drupal file hierarchy, so that they can be referenced by your post. However, these images need to be encoded as text, because of the xml-based conversation that it's having with the remote client.

Drupal uses the Movable Type API, which is quite well supported generally, and Mars Edit is smart enough to know that - so that when you set up your blog account in Mars Edit for the first time, it generally gets the settings correct.

There are a few gotchas though, and as I spent a good few hours on this, I thought I'd share:

Firstly, you need to get BlogAPI installed. Install it as you would any other Drupal module, but be sure to turn on the supporting API providers - MetaWeblog and Movable Type - in the Modules list. Apparently we need both, as some key functions seem to reside in MetaWeblog.

Next, be sure to grant permissions. This may seem obvious, but I spent a frustrating hour trying to post images as the superuser, and failing. Even if your account is UID=1, you'll still need to create a role, add yourself to it, and give it perms for BlogAPI. If you don't, you'll be able to post text just fine, but BlogAPI will refuse your images, because you won't have a valid file upload limit.

If you'd like to be able to push posts up in Draft (unpublished) status, you'll need "Administer Content" perms as well - grant that to your role, again even if you're user #1.

Finally, if you're getting complaints about the SQL schema, as I was, just uninstall BlogAPI (that means uninstalling the providers first - and I do mean uninstall at /admin/modules/uninstall, not just "turn off"). Turn BlogAPI back on again, and it will re-make the database tables it needs. You will then have to reactive the providers, and set everything up again at /admin/config/services/blogapi. I think this may have something to do with the update - perhaps the BlogAPI updater doesn't quite handle the jump from D6 to D7. Anyhow reinstalling solved it for me.