Tag: Wordpress

  • A WordPress-Nextcloud writing workflow

    I spend a large part of my time working on my website, which is an essential part of my business. The site is about the history of Venice, considered very widely, and a lot of studying and drafting goes into it.

    My main website is self-hosted WordPress, but WordPress is not sufficient for what I do.

    The preparatory work going into writing for the website, requires space for literature, sources, images, maps, notes, brainstorming drafts and much more.

    If I tried to do that in WordPress, it would be an unwieldy mess of uploaded gigabytes of PDFs and other files, which I would have to keep locally too.

    A private Nextcloud instance is a much better solution.

    With Nextcloud, I have a web-interface to the files with a set of remote apps and functions available, but I also have all the files locally. The synching is fast enough to allow me to switch between remote and local apps without any real problems.

    The basic writing-publishing process

    As I do my History Walks in Venice, I sometimes get questions I haven’t got before, or see things I hadn’t noticed before.

    That will send me back to my books to find an answer. More often than not, I’ll stumble over something else in the process, which might be worth my time later. Consequently, I often have many articles in the pipeline at any one time.

    The process is more or less this:

    1. Reading notes, odd ideas and what not goes into Nextcloud Notes, either as plain text or Markdown formatted. There’s a handy Nextcloud Notes app for the phone, there’s the normal Nextcloud web interface, and the files are mirrored on my computers. I therefore have easy access to these files anywhere, and can edit them with just about anything.
    2. Once a theme for an article or newsletter coagulates, I move the note to the Drafts folder in Nextcloud, and start finding images, making maps, compiling lists, translating sources or whatever is needed to back up the article. Any writing here also happens in Markdown format. I use whatever program I feel like to edit these files. Common choices are the rich-text editor in Nextcloud, Emacs or Apostrophe, but it is a simple text file which can be edited with any editor.
    3. I don’t always know exactly where a text will go on the website, as I have several custom post-types: posts, articles, newsletters, translations, and so on. Often the text will therefore enter as a custom ‘Scratchpad’ post-type, where I can do all the preparations for publishing, such as uploading images, tagging names and places, entering the bibliography, adding footnotes and such.
    4. When I’m done, I move the ‘Scratchpad’ post to the section of the site where it belongs, and schedule it for publishing. If it’s a newsletter, there’s a separate procedure to send that to the subscribers.
    5. Once the article is published on the website, I add links to it from older existing articles, where relevant. For this, I use two custom plugins. One tracks the internal linking structure of the site, so I can easily see which posts link to which, and another which implements a unified search function across all post-types.
    6. The last thing to do is sharing the article on social media. I do this manually, as most walled garden social media has made automated procedures even more cumbersome.
    7. The last last thing, is to move the article draft folder to the folder for published posts, with the date of publishing added to the folder name. If, for some reason, I need to return to the article later, I can easily find everything I used there.

    WordPress and Markdown

    In the early phases, I write in Markdown, but when the text enters WordPress it becomes HTML.

    This is automatic. I very rarely need to do anything.

    When writing in Markdown, I only use the basics: headers, links, bold, cursive, lists, and quotes. I never add images to the Markdown files, and I usually also stay clear of tables.

    To move a Markdown text into WordPress, I simply copy the Markdown formatted text to the clipboard, and paste it into the Gutenberg on WordPress. The Gutenberg block editor will automatically convert Markdown formatting into Gutenberg blocks, and it does a decent job.

    I don’t mind the Gutenberg block editor. It is great for all the visual aspects of how an article is presented, but it doesn’t suit me well for the earlier phases of writing.

    Markdown is perfect for that.

    If I need a distraction-free environment, I can do that easily with the Nextcloud editor or Apostrophe. If I need to do complicated search and replace, or very repetitive operations, or sometimes just anything but churning out words, I use Emacs.

    Writing aids

    English is not my native language, so it is easy to make mistakes.

    Initially, I used the integrated writing aids of the WordPress plugin Yoast SEO. They are, however, rather limited, and they forced me to do more of my workflow in WordPress than I cared for.

    Searching for something else, I discovered LanguageTool, which I find more useful. It offers me many more corrections, and it works in more contexts.

    It works in almost anything browser-based, so it’s there in the Gutenberg editor, and in the rich text editor of Nextcloud. I can also use it in LibreOffice and Thunderbird, with the necessary extensions.

    Why self-hosted?

    It has always been my preference to run my own services. I simply don’t trust big foreign corporations with all my data.

    The problem isn’t as much the confidentiality of the material, which is very low, but the amount of time I have invested in collecting, organising and writing everything.

    It would be very disruptive for my work to get kicked out of my digital office and library by some AI algorithm which mistakes a Renaissance painting by Titian of a nude girl for child pornography,

    In principle, any such provider could shut me down for anything, even a copy of a painting. If that sounds ridiculous, be assured that more ridiculous stuff has happened, and that you’ll have no recourse.

    I would have to keep copies of everything offline somewhere anyway, so what’s the point.

    One last point, in these times of AI — which is an illogical abbreviation for Automated Plagiarism — I don’t want everything I do to be used to train the AI models of big corporations.

  • Hyphens and dashes in WordPress

    I’ve often been uncertain about what WordPress does with one or more hyphens in various contexts, and even looking at the code of wptexturize is that useful — not all code is poetry.

    One or more hyphens can produce a single hyphen (-), an en dash (–) or an em dash (—), but it’s not entirely straightforward.

    TL;DR

    A single hyphen becomes an en-dash if surrounded by spaces. Otherwise, it remains a hyphen.

    Double hyphens become an em-dash if surrounded by spaces. Otherwise, they become an en-dash.

    Triple hyphens always become an em-dash.

    Common usage

    Number ranges with en-dashes require double hyphens, as in 5–6. Otherwise, you’ll get a hyphen, like 5-6.

    Em-dashes used as punctuation—normally without any spaces around—need to be entered as triple hyphens. If used with spaces around — which is not the common usage, however — double or triple hyphens work the same.

    See — for example — How to Use Em Dashes (—), En Dashes (–), and Hyphens (-) on Merriam-Webster.

    Test tables

    Single hyphens

    InputOutputResultNote
    -–en dashalone
    word-wordword-wordhyphensurrounded by letters
    word - wordword – worden dashbetween words with spaces
    word- wordword- wordhyphenspace after
    word -wordword -wordhyphenspace before
    5-55-5hyphenbetween digits
    5 - 55 – 5en dashbetween digits with spaces

    Double hyphens

    InputOutputResultNote
    --—em dashalone
    word--wordword–worden dashsurrounded by letters
    word -- wordword — wordem dashbetween words with spaces
    word-- wordword– worden dashspace after
    word --wordword –worden dashspace before
    5--55–5en dashbetween digits
    5 -- 55 — 5em dashbetween digits with spaces

    Triple hyphens

    InputOutputResultNote
    ---—em dashalone
    word---wordword—wordem dashsurrounded by letters
    word --- wordword — wordem dashbetween words with spaces
    5---55—5em dashbetween digits
    5 --- 55 — 5em dashbetween digits with spaces
  • WordPress Full Site Editing

    WordPress Full Site Editing

    In the past I’ve been happily fiddling with WordPress themes and plugins manually, but with the new full site Editing system that doesn’t really work any more.

    That’s not bad because you can probably get more effect with less effort using the new system.

    I’m not a designer, so I’ve usually worked with child themes.

    Somehow, an edited theme with the full site editor seems a bit like an old-style child theme. The modifications you make are in the database, and when the parent theme is updated, your changes remain. That was one of the important features of child themes, and that is also how the new system works.

    In that sense there’s little need for child themes.

    What if you want to use your modified theme on several sites?

    Reusing modified themes

    The full site editor has an “Export” option which will create a ZIP file that can be installed somewhere else.

    Nice!

    However, it contains the entire theme with the modifications from the full site editor applied, but with the original name. That means that next time the original theme is updated, the local changes disappear.

    Less nice!

    The “Create Block Theme” plugin

    The nice people at wordpress.org have made a plugin to help with these issues.

    It does several things, and it can also either clone an existing theme, including giving it a new name, or create a child theme of the active theme.

    Cloning themes

    A clone theme is a copy with another name, so an update to the original theme doesn’t overwrite your changes. It is an independent complete theme, and you don’t need to have the original theme installed on the production site.

    Being an independent, complete copy, however, also means that updates to the original theme won’t be applied to the copy.

    This might be fine, or it might not be, depending on what you want.

    Child themes

    A child theme only contains the changes from the parent theme, which must therefore be installed on the site.

    Updates to the unmodified parts of the parent theme will be applied to the child theme automatically, just like with the pre full-site editing child themes.

    First time I did this, the site didn’t work properly. The parent theme had a sidebar for desktop and a top bar for mobile, and both were shown all the time. There was not switch between the two presentations when the browser window changed size, as there should be.

    The problem was that the parent theme’s style sheet wasn’t loaded.

    This might be a bug in the “Create Block Theme” plugin.

    The way around the problem is to export the child theme using the “Create Block Theme” plugin (not the export function in the full-site editor), and add a functions.php file to the ZIP file, containing these lines:

    <?php
    
    add_action( 'wp_enqueue_scripts', function () {
        $parenthandle = 'parent-style';
        $theme        = wp_get_theme();
        wp_enqueue_style( $parenthandle,
    	get_template_directory_uri() . '/style.css',
    	array(),
    	$theme->parent()->get( 'Version' )
        );
    } );
    

    Install the updated ZIP file on the development site. Now the child theme will load both the style.css from the child and from the parent themes.

    Updating the version number

    The themes created with the “Create Block Theme” plugin all have version 0.0.1.

    If you want another version number, you have to change the ZIP file before it is uploaded to the production site.

    Open the ZIP file, and edit the version number in the file style.css.

    I’ve opted for a version number made up of the date and time, as YYYYMMDD.HHMM.

  • WordPress without a web server

    WordPress without a web server

    In the almost two months we’ve spent in Coronavirus lockdown here in Venice, I’ve had the opportunity to get some of the old forgotten tasks done. During one of these I finally got around working with WordPress from the command line, and directly from PHP without running a web server.

    It is amazingly simple. My server is running Debian, and this code is all that’s needed to run WordPress from the command line:

    // The site you want to access using Debian's multisite
    $_SERVER['HTTP_HOST'] = 'wpsights.seindal.dk';
    
    // Location of WP installation on Debian
    define('ABSPATH', '/usr/share/wordpress/');
    
    // Load the beast
    define('WP_USE_THEMES', false);
    require_once(ABSPATH . 'wp-load.php');

    After this WordPress is loaded for the site given by HTTP_HOST and you can do anything you want with the WordPress API.

    Reading a JSON file and inserting 1200 pages in a hierarchy becomes just a few dozens lines of code.

    The background

    The task at hand was migrating a very old site to something more recent. The site in question, sights.seindal.dk, was made almost twenty years ago, and had been abandoned for at least fifteen years. Yet, back then I’ve put in a lot of effort, and the site did have some decent traffic still.

    The old site was programmed in Perl using the Mason framework, with a mysql backend. The new site would be WordPress because it’s ubiquitous and fairly easy to work with, and I have a bunch of other sites on WP.

    There were some 1200 pages on the site, and about 10,000 photos, all meticulously tagged and cross-indexed. Many articles are quite substantial. Everything was cross-linked automatically on the site. I wanted all this moved over, and preferably not by hand.

    In the end I modified the old perl code to export the pages and photo metadata as JSON, and wrote various small scripts in PHP to read the JSON and load everything into WordPress as pages, media, tags and categories.

    Given the ease of using WordPress directly from the command line, I could make many small scripts and do the migration a bit at a time.

    Add to that a child theme of a very basic free theme, and a content filter to do the automatic linking, and the task was done.

    It took about a week to get all the data over, and another week to do the child theme and automatic linking.

  • Mass upload to WordPress

    I often make photo entries on my other non-technical blog, and it is such a pain having to upload photo after photo in two sizes. Yesterday I discovered the Upload Unzipper which implements uploads of zip-files which are then unpacked on the server and treated as individual uploads. Fantastic time saver.
  • Comment spam

    Comment spam

    I just went through the comment moderation queue on this blog, and there were four (4) valid comments out of 385 comments. Spam is such a pain that I can’t even imagine how it would be without comment moderation activated.

  • Blog moved to WordPress

    Blog moved to WordPress

    I finally got my act together at moved this blog to WordPress. There’s still a few lose ends, some uploaded pictures are missing and will have to be added by hand, and the top graphic needs replacing.

    It’ll probably make a mess of those places using the feeds from here. Sorry about that.