Call me picky, but I didn’t want to be forced to use a code block every time I wanted to include a little bit of code. Sometimes, it’s just handier for the code to be inline so it doesn’t disrupt your text, but still clearly looks like code.
In short, just enclose your text in ''%% and %%'' like this:
Here's a sentence I'm typing and ''%%this is code%%'' I want to include inline.
This works beautifully!
Ironically, it’s not shown in the official syntax documentation, except that if you view the source for that documentation, you realize this technique is actually used to put inline code throughout the syntax documentation. 😉
(Now why didn’t I notice that and think to look at the source code? Sheesh.)
TL;DR grep your filesystem for a unique fragment of text that’s likely to only appear in the content you lost when your draft disappeared. Step-by-step instructions here.
Not long ago, we started using DokuWiki as an internal solution for documenting technical details, systems, and best practices in our digital marketing agency. Let me just say that I lovethe software. It’s easy to install and configure, training users on it is relatively painless, and its simplicity makes it an amazing solution for purposes like ours.
But… like any new system, getting accustomed to its quirks can take some time—especially quirks you don’t run into very often.
Today, I was working on a lengthy new page in DokuWiki and I got busy researching something in another browser tab (or 10). Naturally, I hadn’t hit the “Preview” button, nor had I saved a version.
You can probably guess where this is headed.
I returned to the browser tab where I had DokuWiki open and found the dreaded “editing lock expired” message.
Normally, this wouldn’t be a big deal. We aren’t typically handling lots of concurrent users, so often only one of us is doing any editing at one time, much less the same page. And I’ve found that just by clicking one of the options, I can usually get right back to the editor.
But this was a brand new page that hadn’t been saved yet.
And, being in a hurry, I just started clicking buttons and not paying attention to what I was doing. The next thing I knew, I was looking at an empty editing window..
And this was after spending more than an hour working on the content for the page. It was gone. All of it.
The one thing I had going for me is that I had noticed a “draft autosave” message in the browser at one point. So, I went looking to see if I could find the draft.
So… I connected to the server (via SSH) where the instance of DokuWiki was running and started looking around.
After some Googling, I found that by default, DokuWiki drafts are automatically saved in the /data/cache folder, sorted into numbered subfolders.
Issuing the ls -lt command, I could see which subfolders were the most recent ones, and I looked through them. There were no files with a .draft extension, which explained why DokuWiki hadn’t shown me a draft for my page when I re-opened the editor.
But since I knew I had seen the “draft autosave” message previously, I knew there had been a .draft file at one point. Given that the file no longer existed, surely it had been deleted!
Well that’s great… we can undelete files, right?
Not so fast. This particular server is a VPS instance at Digital Ocean that we use for intranet purposes. Being that it’s a VPS, the typical data recovery tools for Linux like TestDisk and foremost aren’t much help. Virtualized disks means virtualized storage… or something. I’m out of my depths here.
Let’s just say that I tried both of them and didn’t get the result I was hoping for.
Recovering Text Files in Linux
Since DokuWiki stores content in text files on the server, it occurred to me that I should look specifically for a means of recovering .txt files (not even one of the available options in foremost, which has command line options for various file types).
A found a tidbit on recovering deleted plain text files in Linux that gave me some hope. And after just a couple of minutes, I found the entire contents of the last “draft” of my DokuWiki page. Here’s exactly how I did it.
Steps to Recover a Deleted DokuWiki Draft in Linux
Browse the filesystem on the server where your DokuWiki installation is located. In my case, I used ssh to connect to our intranet server in a terminal window.
Determine where the partition containing your filesystem is “mounted” in Linux. From my terminal window, I ran the mount command (on the server, of course) to display a list of mounted filesystems (details on the mount command here). Just running the command by itself with no command line options will display the full list. It’s a lengthy, hairy mess.
On a normal Linux workstation (non-virtualized), you’d typically be looking for something like /dev/sda1 or /dev/sdb2. On the Digital Ocean VPS, I spotted a line that began with /dev/vda1 on / type ext4. I decided to give that a try.
Next, you’ll need to recall a bit of text from the page you were writing when your draft got lost. The more unique, the better. Also, the longer, the better.
The command we’re going to run is going to look for bits of text and then kick out the results from its search into a file you can look through. If you use a short or common string of text in the search, then you’ll get a huge file full of useless results (kinda like running a Google search for a common word like “the” would produce).
In my case, I’d been working on some technical documentation that had a very specific file path in it. So I used that as my search string.
Run the command below, substituting your unique phrase for ‘Unique string in text file’ (be sure to wrap your text in single quotes, though) and your filesystem location for /dev/vda1 grep -a -C 200 -F 'Unique string in text file' /dev/vda1 > OutputFile
Wait a few minutes. In my case, the grep command exhausted the available memory before too long and exited.
Look through the file that got created. You could use a command like cat OutputFile or, as long as the file isn’t too huge, you could even open the file in an editor like nano by using nano OutputFile. The advantage to the latter method is that you can then use CTRL+W to search through the file.
On my first attempt, I used a shorter, more common phrase and got an enormous file that was utterly useless. When I gave it some thought and remembered a longer, more unique phrase, the resulting file from the second attempt was much smaller and easier to work with. I found several revisions of my draft, and that gave me options to work with. I decided which was the most complete (recent) and went with it.
Copy the text. You can then paste it somewhere to hold onto it, or just put it right back in DokuWiki. Just be sure you hit “Preview” or “Save” your page this time around.
One quick note: I’m not sure if it was necessary or not, but I actually ran the commands above as “root” by running sudo -i first. I haven’t tested it, but this may actually be a requirement. You might also just be able to preface the commands with a sudo (e.g.sudo grep -a -C 200 -F 'Unique string in text file' /dev/vda1 > OutputFile ). For either of these to work, you’ll obviously need to have an account that has the ability to run sudo.
I hope you find this useful! If so, I’d love to hear about it. Also: if you have questions or problems, you’re welcome to leave those in the comments as well. If I can help, I will gladly do so!
The idea is that you create your content in Google Docs, using all of the lovely collaborative features like multiple (even simultaneous!) authors, commenting, great editing tools, cloud-based storage, and so forth.
Then… once it’s ready to go, push a button and voila! — the content shows up in your WordPress site.
The magic happens thanks to Jetpack, which we users of the WordPress software use to connect up our self-hosted sites to Automattic’s WordPress.com infrastructure.
So… you need to have the Jetpack plugin enabled and your site connected.
Then you need to use the WordPress.com for Google Docs add-in (that link goes to the Google Web Store page for the add-in, but you can also get it by going to “Add-ons” inside a Google Doc).
As much as I love the WordPress editor, this is a game changer. I live in Google Docs, especially since I acquired my first Chromebook about a year ago.
There’s one more hiccup. The authentication passes through multiple layers (after all, you wouldn’t want just anyone editing a Google Doc to be able to push content to your website, would you?):
Your Google Account (make sure you’re signed in to the one you want)
Your WordPress.com account — meaning the account that you used to connect your self-hosted WordPress site up to the Jetpack/WordPress.com infrastructure. (Here again: make you’re signed in to the right one!)
Your local WordPress account (meaning the account that you sign in to your actual WordPress site with)
It was at that last authentication step that I hit a snag:
I had never activated the Jetpack JSON API on this site. So… I had to go through the Authorization process one more time after fixing that.
But hey! Needing to screenshot an error message gave me a chance to see how images work in this whole process. I’ll let you know once this content gets pushed to my WordPress site!
After hitting the “Save Draft” button, my content got magically pushed to this site. (If you hadn’t figured it out, I wrote the first draft of this in Google Docs!)
The image came along with it!
But…. my cropping didn’t. The image above is the full screenshot. In Google Docs, I had cropped it to get rid of the 37 Chrome tabs and so forth (hyperbole, I know, but that’s only one of my 3 current Chrome windows!).
All in all, this is a fantastic experience. There’s even a button in Google Docs to “Preview” the post on the live site, and of course a way to update the draft from Google Docs.
I’m guessing you’ll have to manage your own workflow for which version is the latest. I assume if I make changes on my site, but then hit the “Update Draft” button in Google Docs, that version will overwrite whatever is on the site. But this is to be expected. (And I haven’t tested it yet, so… who knows?)
Now that it’s been officially announced, I’m excited to invite you to join me for a discussion about “Getting Real Business Results from Your Content Marketing Efforts” at WordCamp Miami!
The event runs March 24-26 (Friday through Sunday) at Florida International University in Miami. The Miami gathering is one of the longest-running and most well-respected events in the WordCamp series, and it’s an honor to be invited to participate.
Lastyear, the weekend was outstanding, and my lovely wife, Jill, and I are truly looking forward to another spectacular time in South Florida!
A huge congratulations to my good friend and sometime collaborator, Rod Thomson, on the launch of his new project The Revolutionary Act.
Rod is an insightful thinker with a strong dedication to principles, which makes discussing topics of all kinds with him a joy. He challenges me to think, and I am always the better for it. Not only is he a veteran journalist and a published author, but he’s makes frequent radio and television appearances to discuss public policy and other issues of the day.
I’ve been bugging him for months to start blogging. I’m excited that he’s finally doing it! Can’t wait to see what comes of this!
The Starbucks “Barista” Coffee Grinder, the EL60, is the grinder that just won’t die. It was a present from my beautiful, amazing wife many years ago, and it has truly been a gift that keeps on giving.
Now.. it’s survival isn’t just amazing because it’s really well made. It’s amazing because it continues to chug away despite years of abuse on my part! I’ve written previously about how Baratza helped me replace my broken hopper after the whole grinder took a nasty fall.
This time, it turns out that my fundamental ignorance of how the thing works allowed me to neglect basic maintenance to the point that it became nearly unusable. Here’s what happened.
One day not long ago, I dumped the coffee grounds from the EL60’s bin into my pour over and noticed that it seemed a little light. After years of doing this, I should’ve realized that my instincts were spot on and I was missing some grounds, but I didn’t think too much about it. That cup of coffee brewed up super quick, and was naturally quite weak.
I still didn’t think a whole lot about it until I went on to brew the next cup, and ground up some more beans. This time, the grinder just didn’t seem to ever finish grinding. I’m so in tune with the sound of this thing that the pitch it generates when the RPMs spin up to their max is my aural clue that the grind is complete.
So… I dumped the bin again, and this time I only got a few grounds and some powder.
Powder is a problem. This grinder is known for producing a highly uniform grind… especially for a consumer unit sold en masse by Starbucks.
So… I took the hopper off and peered into the grinder only to discover that there were still nearly untouched coffee beans in the works.
Disassembly from there was a little harder than it should’ve been, mainly due to the aforementioned years of neglect.
But… once I finally got the ring burr to let go of its grip on the holder for the main burr (below), I saw that the entire chamber was full of grinds and shards of beans.
Right away I knew that the motor was fine. It was chugging away just perfectly. The burrs themselves were still sharp—after all, I was getting grinds that were what I expected… plus powder! So that meant that something mechanical was out of whack.
After spending several days cleaning out the grinder chamber with a butter knife after each grind, I decided to completely disassemble the machine and see if I could figure out what was going on.
Here’s what I found:
That little black component is a “door” of sorts, which opens to allow the coffee grinds to escape from the grinding chamber into the little chute which feeds the bin. As you can see, the “doorway” is jammed with grinds… and powdery ones.
Since I’m grinding for a pour-over brewing method and not for espresso, you can imagine that I do not usually grind the beans to powder. So this was all quite mystifying to me.
So… I did what had worked well for me in the past, and reached out via email to Pierce Jens, who has provided outstanding support for me in the past.
Pardon Me While I Rave About Baratza
I’ll get back to the story (and the fix for my grinder) in a moment. But first let me insert a couple of thoughts about Baratza.
Baratza is a company I can get excited about. When I first needed help with my grinder some years ago, I was directed to Baratza by Solis, the European manufacturer that originally built my grinder, with instructions that Baratza was their US distributor and was responsible for support.
It’s unclear to me whether Baratza had anything to do with the original deal that allowed for Starbucks to private label the Solis grinder and distribute it in the US under the “Starbucks Barista” brand when my wife bought this grinder for me many years ago.
What is clear is that Baratza is currently the major supplier for Starbucks grinders, and that those grinders sold by Starbucks wear the Baratza label rather than a Starbucks private label.
So… maybe they made a little money on the original purchase of my grinder, maybe they didn’t. Even if they did, they were a distant 3rd party to the transaction and were completely unknown to consumers like me at the time.
In other words, they could have easily declined to expend any resources on supporting me with my grinder problems. This they did not do.
Additionally, Baratza has advocated quite publicly for keeping grinders out of landfills, a message which, as a jaded marketer, I’ll admit to being a little dubious about. After all, it’s easy to talk about concern for the environment, and it’s another thing entirely to align one’s business practices around it.
In the case of Baratza, I can tell you that they have proven to me through my interactions with them that repairing coffee grinders—whether to keep them out of landfills or to provide outstanding customer service or both—is something that their business practices fully support.
This is impressive.
OK… back to my story.
The Fix for My Jammed Grinder
I found an old email thread from when Pierce Jens, who is a support technician at Baratza, helped me figure out what to do with my broken hopper, and replied to it, including the photo above showing my grinder jammed with coffee grounds.
Ever the master of email support, Pierce waded through the superfluous details I provided and managed to troubleshoot the issue in one round:
Thank you for your kind words! I’m always happy to help troubleshoot, let’s see if we can figure this out. I think you may simply have a worn out paddle wheel. Check out the 3rd picture of the Troubleshoot guide attached. None of the other pictures apply to your machine. You should have an 8 blade paddle, and I suspect yours is worn all the way out. I also have the paddle wheel replacement guide attached and the part is $5 on our Solis parts page.
By the way, your write up about the hopper has made several fellow EL60 owners happy over the years: kudos for that!
What was funny to me was that I had spotted the paddle wheel on the Solis Grinder Parts page on the Baratza website, but assumed that it applied to a different grinder than mine… because I didn’t recognize it!
I knew right away that he was right. So… I placed the order. Within a couple of days, the new part had arrived and I disassembled the grinder once again.
In the photo, there’s the conical burr from my grinder, which I got removed from the machine according to the directions that Pierce provided.
There’s an 8 blade plastic paddle below there… can you see it?
I couldn’t either. Here’s why:
Sure enough, the blades were completely worn, which is why I didn’t recognize the part on their website!
The paddle wheel is responsible for sweeping the grounds out of the grinding chamber and through the shoot to the bin. After many years of use (in my case, anyway), the blades had worn down to the point where they just couldn’t push and grinds out!
I got the new one out of the package and attached it to the burr. Check out the worn one in the background!
Reassembly was a snap. The PDF guides Pierce sent me had plenty of detailed instructions and the whole repair probably took less than 10 minutes.
With the grinder back together, I’m now getting “good as new” performance from my machine.
A couple of lessons learned:
I probably should take a cleaning brush to the burrs on a regular basis. I will admit to having lost my grinder brush many years ago and then forgetting about this whole maintenance step. Had I been doing this, I probably would have noticed the paddles wearing down. In my case, it had been so long since I had had the grinder apart (even enough to just inspect the burrs), that I had completely forgotten those white paddles had ever been there!
Baratza has won my business. They make virtually nothing from selling me parts like this, because the resources they’ve expended to provide support are far costlier than the revenue they’ve generated from the parts (not to mention the profits). That they still provide support via email in this way, and that there’s someone smart enough to employ Pierce Jens tells me that they’re precisely the sort of company I want to do business with.
The final lesson is that I’m probably going to go ahead and order new burrs for my machine as the supply of parts for my grinder is apparently starting to dwindle. Mine are still performing well, but after inspecting them up close, I could definitely see signs of wear that weren’t visible to me prior to completely disassembling the grinder.
Alas… I won’t be needing a new grinder any time soon. But when I do, I’ll be buying Baratza. I certainly highly recommend you do the same!
Oh… and if you’re having trouble with any Baratza grinders, check out their fantastic YouTube channel, where Pierce shows how to perform any number of repairs!
Another huge milestone for our new favorite cartoon superhero, Brushy Bear. Previously, we noted 2 million views on his Facebook videos, but today we congratulate him along with TUNGBrush, makers of the best-selling tongue cleaner, on hitting 2 million views for a single video!