Wordpress – RAnt(hony)-ings

Gutenberg Editor Bug

February 22, 2021 – Updating and moving this generic article forward for a new bug in Gutenberg. I don’t know how many users have run across this one yet, but I have. I have several snippets of HTML code that I like to reuse. I do this because it streamlines getting things I want to regularly add to my posts added without having to lookup or re-enter the code over and over again. Things like podcast embeds and the like (the subject of the previous bug I wrote about here, actually) well, they changed the way that reusable blocks work, again.

This bug report touches on the problem that I am experiencing: Comparing old and new Reusable block UX methods. #29178. It doesn’t quite cover the problem, though. Part of the usefulness of the reusable blocks was the ability to explode said blocks back down into base elements, such as code blocks and text strings and whatever. The ability to take pieces out of the reusable block has changed along with the editability of the blocks, and the dot next to the publish button stays present even if I completely remove the reusable block from the document being edited, because I have to change the block in question in order to be able to remove it.

Here is a snippet of my screen as an example. One of the blocks that I frequently did use was an HTML block that was just a horizontal rule (named “Separator”) that I could manipulate to suit my own visual issues. Basically, I wanted the rule to be of a particular length and a particular number of pixels. I am not really a coder, I’m just a user who is forced on occasion to fiddle with code, and I’m okay with this situation, as long as it doesn’t mean I have to code every single time I sit down to write something.

As you can see from the image, the block now sees itself as a group, not a single HTML code block like the Audio Embed block next to it. This is because I inserted the block and then saved the document I placed the block in. As soon as the code block is inserted into a document, it turns itself into a group. Unless you know to turn off saving reusable blocks at the prompt, this error will occur every time you use a reusable block and then save the document the block is placed in.

If you place the reusable block and then try to delete it, the group remains without the block you’ve added. The best part of this is that saving after you think you’ve removed the reusable blocks and not noticed the prompt is that if you save blocks that you thought you completely removed from your document, the editor creates empty group blocks in place of the reusable block that you had previously created. Without the ability to just remove the block and not have it turn itself into a group; without the ability to explode a block and reduce it to simple code and text, the end user is left with having to leave multiple tabs open set to various configurations of files just to be able to assemble a single document. A process that simply isn’t feasible on a mobile platform, for example.

h/t to paaljoachim for creating three bugs reports to deal with these issues 29267, 29268, 29269. The conversion back to standard blocks function was moved to a button on the bar from the pulldown menu at the end of the bar (bug 29268) I honestly don’t know if the overlapping squares button would break reusable blocks into standard blocks before I noticed the other new behavior that was so frustrating, but as of 3/9/21 it was working to do the job I wanted done. Thank you to mtias for pointing this out.

November 4, 2020 – This bug has to do with inserting coding blocks into the text that I’m working on. Like images, I occasionally have need to reference a specific podcast, either one that has sent me off on this fool’s errand of illumination, or one I want to provide to readers in order to give them some understanding of where I am coming from. Podcasters are as plentiful as the various kinds of life in a rainforest, and their approaches to embedding, whether it is even allowed or not, varies almost as much as the podcasters themselves.

The most plentiful podcaster out there at the moment is NPR. They are everywhere, all the time, and I link their podcasts as frequently as I link podcasts from any other source. However, the current version of Gutenberg does not recognize the embed codes for NPR podcasts, just like it has never recognized most of the embed codes for other podcasts.

This has never been a problem before because I have simply been able to introduce my own code into the text, taking the place of a paragraph, and that has solved the problem. Now the wise coders working on Gutenberg have seen fit take out my ability to write my own code into the text automatically, and I have to go to extreme lengths just to be able to get my code to appear unmolested in the published article.

I had a reusable block that I called Generic Embed. In that block I had assembled the code that rendered something like what I expected to see in the finished blog article. That block isn’t even visible in the block interface anymore. I have to scroll to the bottom of the reusable block list and select Manage all reusable blocks, and then find the block within the list of reusable blocks that I have created.

Looking at that list I can see that it is time to thin the reusable blocks down again. However, I can show you the code that is in the block because there are a couple of blocks that let me do this for you. Here is the code:

<figure><iframe src="embed url"></iframe><figcaption><span style="font-size:8px"><em><a href="webpage">author - page title - date</a></em></span></figcaption><br></figure>

That is the default block for verse. I suspected that block would leave the code alone because I’ve transformed text into verse in the past and it faithfully reproduces the verse exactly as typed within the constraints of the screen that is displaying the text.

If you use the default code block provided with the Gutenberg editor you will have to use an HTML encoder (h/t to the users at Stackoverflow for the tips) to change the code into the escape strings necessary to reproduce the code. Why this process is not automated within the block is beyond me.

Using the encoder I can now put the transmogrified code strings into the code block and get displayed text that looks like the verse block does just by pasting the actual code into it:

<figure><iframe src="embed url"></iframe><figcaption><span style="font-size:8px"><em><a href="webpage">author - page title - date</a></em></span></figcaption><br></figure>

In trying to present the raw code, I discovered that the ever helpful WYSIWYG is trying to make the code do things even when it is NOT SUPPOSED TO DO ANYTHING TO THE CODE except to display it as code. In the various tests I have conducted trying to discover a work-around, hours of trial and error and research into coding and displaying code that I should have learned years ago, I was driven to near madness trying to figure out why I could not just paste text as typed directly into the interface. No. I have to learn how to decode and recode in order to explain anything.

Modern day problems, being driven into a homicidal rage by things that should work one way but don’t because no one ever thought to eliminate that step in the process. However, my lack of formal training aside, this embed error shouldn’t have been allowed out in a supposedly finished product. A product people pay for. Thankfully, I don’t pay for it, or I’d be more pissed off than I am. Maybe you should fix this problem, WordPress?

In the meantime, I will come up with a work around for my podcast embeds, which will involve simply putting a dumb HTML block into the text and then manually adding the code that I want to appear there. It is a more time-consuming process to do it this way, but I will soldier on until the next update for Gutenberg fixes this bug and breaks something else.

Like the image bug that is documented below (but remains fixed, please don’t break that!) the embed bug also produces embedded objects that I cannot manipulate and captions that appear too large, but are manipulable from the settings menu, which does show up above and to the right if you have those menus turned on. The block isn’t there for all intents and purposes and can only be found by clicking off the object and moving the cursor so that it enters the embed, or selecting it from the pulldown at the top of the screen. Also, if you modify the text in the caption you will cause an irrecoverable block error and then have to do the whole thing over again.

The constrictions on adding a horizontal rule to a document have annoyed me from the first day that I worked with WordPress, even before Gutenberg. To be fully honest about my frustrations here, there have been no text editors that have ever been exactly what I wanted when it comes to presenting my words the way I want them seen, with proper margins, font styles, display graphics, etcetera. Every word processor has some deficiency that has left me cold towards it, and so being unsatisfied with all of them as much as I remain unsatisfied with my words themselves, I simply try to make do with whatever tools I have to work with.

I’ve finally come up with a version of the <hr> that displays properly within the Gutenberg editor specifically and WordPress in general.

<hr style="width:44%;height:3px" class="aligncenter">

Now that I know you have to generate escape strings to display code properly in the code box (again, why?) I can now display the code that works for me. Fingers crossed that they’ll automate that process. Or maybe not. That might get broken too if they try it. The verse block works so how hard is it to do a grey background (that for some reason means “code”) that doesn’t screw with your pasted text exactly like the verse box does?

March 14, 2020 – The latest release of the WordPress Gutenberg editor has dumbed down the editor to the point that it won’t work properly in the desktop interface. Basically, I can’t manipulate the images embedded in the text of my articles because the handles that show up at the manipulable edges of images disappear after the image is initially placed.

unusualjuggernaut.tumblr.com (I can’t click on this image in the desktop editor. For all intents and purposes, it isn’t in the document. I can go to the shiney-new block navigation hamburger and select the image block from the list. However, I can right-arrow scroll right out of the caption area but cannot left-arrow scroll back into it. I have to, once again, go to the hamburger and select the image block. This behavior could not be more annoying.)

Color me unimpressed with the latest release. I look forward to the next release, when they fix that bug and I can edit properly again.

Gutenberg version 7.8.1 seems to have fixed the image manipulation problem. I’ll leave the above block as I created it just as a reminder of the annoyance I felt at the time.

Facebook/Instagram Embeds

WordPress stopped supporting interactive embeds for Facebook and instagram back at the end of October. Facebook was changing the way that their content was going to work with outside sources like WordPress and other publishing platforms, making it necessary for anyone who wanted to have interactive embedding on their platform to maintain a official relationship with Facebook (an official relationship that probably has dollar figures attached to it) if you didn’t do this new thing that Facebook wanted, Facebook was going to cripple your ability to embed their content.

Back when I was writing on Blogger, I never had the really nice ability to just pop in a link to outside material and have it work seamlessly inside my blog articles. If I wanted to post my comments to Robert Reich’s or Stonekettle’s or whoever’s work on Facebook, or include photos from Instagram, I had to make a picture of the thing and embed that in my article, then manually add caption material to the image in order for readers to find what I was talking about.

When I started writing on WordPress I realized just how arcane the entire blog-writing process had become on Blogger. It was possible to embed all kinds of material from outside sources directly into my articles and never have to take another screenshot again unless I wanted to pretty up the article when linked somewhere else. Now that Facebook has decided it will take its toys and leave the sandbox, I realized just how spoiled I had become. It was going to be a serious pain the ass to go back and re-edit all those articles that I had put interactive links into, replacing the links with images like I used to have to do on Blogger.

Luckily for me I was given a heads-up on the upcoming changes, and the fact that WordPress was going to stop supporting Facebook and Instagram embeds as part of their core editing interface. That heads-up came in the form of a recommendation that I install some new plugins for WordPress that would handle the issue for me.

There are a lot of plugins for WordPress that you really do need to have installed if you are going to be using WordPress at all. Essential things that need to be addressed such as website administrator security and spam comment filters and a whole host of other things that I might or might not get around to writing about when I finally finish the article I threatened to write two years ago when I migrated to WordPress and realized how much work was involved in just leaving Blogger and taking my stuff with me.

So adding two more plugins to handle Facebook and Instagram embeds? Not a big deal. I looked them up. Lots of installs for the plugins. Very highly rated plugins. So I installed them and I’ve had no complaints. Had no complaints until I noticed a curious problem with disappearing captions.

The only reason this article exists on the blog today is because the Smash Balloon plugin put a nagger on the top of my editing screen and encouraged me to leave a review for their plugins, since I loved them so much. This was the review I wrote for them.

I’m happy that these plugins exist, the Smash Balloon Custom Facebook Feed and the Smash Balloon Instagram Feed. You could say I’m ecstatic, even. I mean, since WordPress decided that they wouldn’t do the required work that Facebook added to the ability to link directly and interactively to Facebook and Instagram articles, someone was going to have to do the work for them and I certainly wasn’t going to be able to do the work myself. I would just go back to screenshotting the articles I wanted to discuss on the blog and then add captions back to them for anyone interested enough in the source to go look at the original article.

Captions are the problem with these plugins, though. I can add captions to them when I’m editing and they will show up in the article. But if I go back in and re-edit (as any writer does and should do) the captions are strippped off of the embed and I have to recreate them again. This is more than a little maddening since historically I have left off linking information and so lost access to source material when that material went offline later. With captions I can at least go look on archive.org or the google archive for historical information about missing articles. When the plugin then strips the data that I’ve taken the time to put into my captions specifically because I don’t want to lose the original linking information, it is basically breaking the thing that I take extra time and effort to do. In the meantime I will pull captions off of the embeds and put them under the linked article in a separate paragraph (like I used to have to do on blogger) but it seems like a cludgy way to get around a plugin behavior that I never encountered when WordPress was doing this work for me. If someone could fix that issue, that would be great.

wordpress.org

I just tested it with an Instagram embed. I hadn’t actually used the Instagram embed plugin before, but lo and behold I had an article that had an instagram embed in it (I did remember writing one) that I hadn’t published before today. Weirdly enough, Instagram embeds don’t strip the captions off of the embed, only Facebook embeds rebuild themselves each time you open them, stripping off the captions in the process. So, there you go. Just figure out why the Instagram one works right.

The Dreaded Web Host Manager

The next to last paragraph in the first article on this subject went like this,

Going hand in hand with Cpanel is WHM, the WebHost Manager (this will be important in the next section) Their user documentation is here and here. If your web host uses Apache they are most likely going to be using Cpanel and WHM as the control panel and manager for the hosting service. Once you have signed up with a web host you are now dabbling in web hosting, at least vicariously. WHM is your best friend when managing a web host. You should probably get to know your new best friend better.

If your site is part of another site, you might have more to do than just trying to break your new web host’s software. You have real work to do breaking other stuff first. Before doing anything else, even if you have a completely new site, you should probably make sure that you have a clean backup of your current website. This is the kind of common advice that gets a well duh response, but every time there is an unrecoverable oops event, it is because someone ignored the well duh advice. Backing up isn’t the easiest thing to do with a hosted web account. It isn’t easy because a simple duplication of your online files will not give you something that you can restore your site from. Backup in cpanel requires you to backup your files and databases separately if you want them to be available to be used to restore an oops event. So do a backup, and then keep reading.

No, Seriously. Backup!

Done? Good. So now you want to create your new website, right? A personal place all your own to host your blog on. You want to create a separate web site because you are borrowing space from a lifelong companion not known for her neat, organized workspace (Ouch! Don’t throw things at me! It’s true and you know it!) and you’d like to know what part of this mess is yours to deal with. This will require you to access WHM, the WebHost Manager. Since you are creating an account for yourself (or myself, in this case) be generous. But don’t worry, you can change the package and account settings later. As is typical with linux GUI’s, some of the settings will say they have been changed or can have particular values, but the implementation of the setting may fail because of limitations that your web host places on your account. This is the one bright point about hosting for yourself, the thing I told you that you didn’t want to do in the first installment of this series. The only bright spot in self hosting, being able to set any hosting variable to any allowed value. This isn’t necessarily a good thing.

Make sure that autoSSL is included as part of the feature set of whatever package you end up creating. SSL? Secure Sockets Layer. It allows you and your visitors to establish an encrypted connection between the two of you. AutoSSL generates a certificate for you at your new hosting location, so you will want it enabled. If it isn’t, you will not be able to be certified as an HTTPS location on the web, and that is bad on today’s internet using todays browsers. WHM will generate an error if you set your bandwidth to unlimited and disk usage to unlimited when you set up your package, and this error will keep you from successfully creating an SSL certificate. You can set the bandwidth to 100GB if you want (one hell of a lot of data) It just can’t be unlimited. Like I said, not a good thing to be able to muck about with all the settings.

Once you have your package set up the way you want it, the way you are allowed to set it up, create your account from the create new account tab on the sidebar menu. Select the package you just created. If you followed your web hosts rules correctly it should show as green and selectable. If you aren’t planning to resell or offer to piggyback your needy relatives on your web host, you can skip package creation and just go straight to account creation. When you get to the menu for “select package” simply toggle the Select Options Manually checkbox, and you can piss off your web host all over again by selecting values that aren’t allowed while simultaneously creating your account. This will save you the trouble of trying to figure out what your web host will allow while creating the package that you will only need once anyway, but you won’t get to give it that special name if you don’t create the package in advance. For me, naming is important. You may be content to let someone else pick the names you use. To each his own.

Get the important stuff right! Check the domain name. Check the user name. Write down the password. Make sure the email address is a working email address. The only default setting that I needed to change on our web host was toggling the recommended setting for mail routing to Automatically Detect Configuration because, again, if if the host can find it, it will find it. If not, you can always figure out what it is later. Hit Create and you are done.

Now comes the fun part, and when I say fun I mean tooth extraction levels of pain. But fun, you know? Since you are migrating your (my) wordpress installation, you’ll have to duplicate the SQL database that makes the installation do what it does in its current location. SQL? Sequel. Structured Query Language. You don’t really need to know what it does (but the link will tell you all about it) you just need to know that you need it. If you only copy the files from the software installation that you are migrating, you may or may not notice parts of your installation working the same way later. You’ll need to access PHP admin. PHP? It’s yet another scripting language (see? Fun!) PHP stood for Personal Home Pages back at the dawn of time, but now stands for Hypertext Pre-processor. I think we’re up to version 7 as I type this. I seriously couldn’t care less. I wish I could work up to caring at least a little. Trying to make Linux work for a decade burned me out on caring about coding, one failed install at a time. AutoCAD Lisp was a walk in the park next to getting Linux to run on mystery hardware. Now I just want the software to WORK, DAMMNIT! I want it to work pretty much 24/7 without my having to do anything about it. It’s enough to make you wish you had the money to pay Squarespace to do this all for you. But I digress.

Accessing the PHP manager will allow you to copy out your SQL commands so that they can be applied to your new account. You’ll want to follow the directions of your web host for doing this. Just make sure you verify which SQL command list is associated with your current install beforehand, then go to the PHP manager, highlight the right one (not expand it) and make sure that, add DROP TABLE/ VIEW/ PROCEDURE/ FUNCTION is selected. This should be in the options section. Export as SQL. Next you will go into your new account, use the SQL wizard to create a new database, associate the database with the user for the account, and then import the SQL file you downloaded earlier. Wipe the sweat off your brow, because that was the hard part of this process.

Time to export all those collected years of hard work. Don’t slip up! Grab your current install of WordPress from the directory that it is in. It should be about twenty-two files, four of which are folders, including one named wp-content. Once you have located those files, zip them up through the cPanel file manager interface, and download them to your local drive. Then you open your new account, go to the file manager, and upload the same zip file to a directory there. I suggest using the tmp directory. That is what temporary directories are for, things you will delete later. move the files and folders from where they land in tmp and paste them to the public_html folder. Verify that the file and folder structure matches your previous files and folders before doing anything else.

Now it is back to coding, again (I’m sorry) You will need to edit your wp-config file in order to modify a few commands so that they point to the new SQL database. This is where writing down your username, password and SQL command list name comes in handy. Open the wp-config.php file in a text editor, like Windows notepad or the native editor in CPanel. Scroll to the lines in the file that say DB_NAME, DB_USER and DB_PASSWORD and then modify the SQL database name username and password with the information that you wrote down previously. Because you wrote it down like I said, right?

Put on your dunce cap, because it’s time for a test! Don’t Panic! This is a website test, you won’t have to cram for the exam. To conduct this test you will need to modify your WordPress config file in the new location, similar to what we did in the last paragraph. There are other ways to test the configuration including logging into the wordpress installation directly and altering the file storage location in settings, and modifying the SQL database to point to the new location, but the test method I chose was modifying the wp-config.php file because I was in that file already. Insert two lines into the code that read as follows, replacing yoururl with the URL that your new installation is currently residing at.

define('WP_HOME','http://yoururl');

define('WP_SITEURL','http://yoururl');

After you do that go back to your original installation location and backup the existing WordPress installations wp-config.php file. After you do that replace the wp-config.php file with an empty text file by creating a new file with that name. This is just a test, and if you backed up like I told you to, you can always revert to the correct wp-config.php if the test fails. Then open your browser and type in your test URL and click on a few links to make sure that everything displays properly.

Nothing sideways? Everything where it is supposed to be and working correctly? Great!

Once you are satisfied that the new installation is working correctly, you can reedit the new locations wp-config.php with your real URL name, and then redirect your URL to point to the new location on your web host. You do this from within CPanel in your old location, deleting the URL from the Domains menu, and then adding the URL to your new location. Once you have successfully moved the URL to your new web host location, you are done. Log back on your site and bask in marvel of your unique genius and programming wizardry. Unless of course, the site doesn’t come up like it is supposed to. If not, go back through the steps and make sure you hit all the points correctly.

If all else fails, even the cheapest of web hosting sites will have some form of chat available to paying customers. Log on the chat and see if they can help you. Just don’t panic. It’s just electrons whizzing around in space. It isn’t the end of the world if the website is down a few days. You’ll get it back up because you made a backup, and you didn’t delete the old installation yet.

Wait. You did make a backup, right? Oops?

If you work with writing text online long enough, and if you don’t want to sign away the rights to your product by just typing it into Facebook or Twitter or one of the other corporate properties squatting on the internet these days, then you are going to run into the need to work on your writing from anywhere and on pretty much anything with a monitor and a keyboard.

Keyboards are essential for thinking. That is my version of only being able to design with a pencil in your hand, the last generations response to my insistence that I could design on a computer. A hundred years ago it would be a pen was required for thinking and a hundred years before that it would have been the quill is required for thinking. The next generation will insist that haptic gloves and an immersive 3D environment are required for thinking. The generation after that will just be directly interfacing with their tech and won’t understand the point of this paragraph at all. Thinking just happens. What do you mean you need a tool to access what is always there all the time?

In the meantime the internet disappears on occasion and you still want to work. You want to design something new and keep it from the public eye until it is ready to be seen. What you want is a local installation of your web interfaces. What you want is a personal web host manager that you can manage for yourself.

If you are trying to do a local installation of WordPress then you will need your own version of a web host manager, one designed for installation on a private system and managing only the websites that you host for yourself. That is, if you have the forethought to do your editing locally rather than in the cloud in the first place. In which case when the internet disappears, so does all your work. Until it comes back. Yes I’ve been cooling my heels a lot lately, why do you ask?

The Wife pointed me in the direction of WP Beginner as a resource that she tapped frequently while learning the ropes of designing websites with WordPress. When I searched on their site for pointers on how to set up a local version of my website for editing and testing purposes, I discovered that their number one suggestion and WordPress’ number one suggestion were the same.

So I installed Local (formerly Flywheel) on my editing computer and then struggled to get an archive of the website built that could be read by Local. Every attempt failed until I also installed the WP Migrate plugin into my WordPress website. The archive created by WP Migrate loaded easily, if not completely accurately. It seems that naming your website differently than your online website will break the established page setups within your WordPress installation. I’m fiddling with that confounding factor now. It is very important that you don’t name your local sites exactly the same as your online websites. This much I know for sure because I’ve now screwed up the security setting on my web browser by trying that. Deleting the local site and restarting the system corrected the error. On to the next thing I can break.

There’s also the problem of usability when it comes to putting Local and WP Migrate together since WP Migrate will require an annual subscription in exchange for being allowed to port changes between the two installations seamlessly. You can’t even use WP Migrate Lite to import anything into an existing site, even to use WP Migrate to put data into a testbed that already exists locally. This makes the name WP Migrate a lie in that you can’t migrate anything from one host to another without paying them. WP Migrate Lite should more properly be named WP Backup, and it would suck as a backup even then because you can’t properly restore from that backup without paying someone to let you do a restoration. I’m removing the plugin as I type this.

You can import an Updraft Plus backup into a fresh install of WordPress on Local. My first barrier for creating a local testbed is going to be the 1,000+ bad links in the existing site. I’ve been working on this problem for three years, ever since the rage incident that stimulated the creation of this post and the other WordPress blogging posts, if not the move to WordPress itself which was a little farther back in time than 2020. But not much (Damn you, Blogger!) The Broken Link Checker is a plugin that every WordPress site should probably be running. Discovering the plugin has seriously increased my faith in the stability of the current site, even with all its errors.

I have discovered the problem with just duplicating the site locally. Because the local site can’t be distinguished from the live site, none of the automation that makes a modern website work so seamlessly can be relied upon in a duplicate testing environment; essentially, the duplicate finds the live site and uses its resources as its own. This will require a migration script to be run on the SQL database, changing the links in the code to point to the local test bed (a fact that website coders have probably been aware of for decades, and I just discovered today by purposefully breaking things. Again) This is why the bad links will be a problem for creating a local testbed. If the links already don’t work, they won’t be redirected to the new migration site, either. Also, I will have to pay Updraft Plus to run the script as part of the migration to the new local site. This makes them useful as a backup/restore tool and a migration tool if you are just moving your website to a new host, but useless for making your desire to edit locally a reality.

The all-in-one WP Migration tool will indeed export a migration to file for free; however importing a site over 300 MB will incur a cost. Exporting to something other than straight to file will also incur a cost. I get it, interoperability has to be maintained. That means it costs money. However, the artificial limit of 300 MB to import a site is entirely a trap intended to get the unwary to pay for something which costs the programmers nothing over the cost of just programming the plugin in the first place. Here’s some advice for you programmers; if you want someone to chip a few bucks in, say so up front. Most people will throw a few bucks at you. Surprising someone on the backend with a surcharge is just another confidence game; and anyone who will play confidence games with me is someone I won’t trust with the keys to my data. Goodbye.

Testing continues.

Web Hosting? What’s That?

When I transferred the blog to WordPress I promised to write a guide to creating your blog on WordPress, or at least describe how I transferred the blog from Google’s Blogger service to a self-hosted installation of WordPress. Well, the guide to how this might be done really has to start with getting your own site up and running, not with the process of getting 10+ years of Blogger blog entries to appear in WordPress. WordPress is hands down one of the best ways to get your writing in front of people who want to read it, but WordPress is just the front end of a process that starts with deciding on a web host.

So, starting from the beginning, the question is should you self-host or should you pay someone to host your site? You can self-host your own website, we did that for years on a Dell PC that we had bought for me to do CAD on. We slapped a second NIC card in it and it was the router/web host for the family until it died a few years back. When we set that system up we had programmers who worked for Dell wandering in and out of the house on a pretty regular basis. It was a simple thing to get one of them to set up a Linux shell on the old CAD system, load Apache on it, do their programming magic, and presto we had a webhost. A black box that I never did manage to figure out how not to break, so I left it alone aside from editing my homepage. I had a static page on ranthonysteele.com that I paid for for years and years for no good reason other than that I figured I needed a website. I was a technologist, a CAD evangelist, and I was quite full of confidence in my unique abilities back when the internet was young and I was certain that the best times in life were still ahead of me.

But this article isn’t about how poor health can ambush and destroy the best laid plans of men. Anyone who doubts this is true should read up on the life of Alexander the Great. The greatest conqueror on the face of the Earth then or now, who was rudely interrupted in the middle of his conquest of Asia with a sudden illness and subsequent painful death. My life plans were much less grandiose than that, and don’t involve the enslavement of entire regions of the planet, and I’m not dead (at least not yet) so I’ve been diverted and not canceled, at least. But being here writing about how to get blogging software to work on a site you run yourself was not where I wanted to be eighteen years down the road. And I’m still not up to that, or up to recommending that you self-host even the most basic site on today’s internet.

I never got the hang of programming. I never found any joy in it. I just wanted to be able to program a website without having to do all the work involved in writing all the code for myself on top of all of the CAD work that I was already engaged in at the time. I knew I hated writing code from the few times that I tested/edited/wrote lisp scripts for AutoCAD. Luckily we had some real programmers on staff at one of the architecture offices I worked for, so most of my work with scripts was testing and not writing. But I did enough of it that I knew that the fiddly, nitpicking work of making sure that every character in the code was absolutely perfect was not what I wanted to do with the rest of my life. So the static page remained static for years on end, while I relied on Blogger to keep doing their Blogger thing as a few years turned into ten and then into fifteen.

The Wife on the other hand needed to maintain her professional presence in the digital world. She had to create and maintain websites through all of the really early years of the world wide web, websites for many different versions of her own professional abilities (effects, actor, producer, unlicensed broadcast engineer, etc) and eventually she wound up maintaining websites for many different people. When she first started using her current web host she set up a demonstration account to show me what we could do with blogging software. I thought it was interesting but maintaining my own website looked too much like programming to me. Besides, I had a history on Blogger and I didn’t want to lose it.

…And then Blogger started to show the effects of Google not seeing blogging as one of its money-making features. The exploitation of programming holes the long unpatched bugs in the web interface not to mention the released and never updated mobile app. So when I turned to her with my Blogger is losing my drafts problem, she threw together another website for me on her hosting service using my old ranthonysteele.com URL, and I was in business for myself. At least to all external observers, I was flying on my own.

Except, I still didn’t understand one damn thing about what it was I was doing. I’m still not a programmer. Learning the in’s and out’s of maintaining a website is much harder than my experience with learning architecture was. Learning how to build something is as simple as wandering through a construction site and asking questions over and over. This is something I’ve done since the town doctor bought property across the street from my family in Leoti, Kansas, and proceeded to have a house built there. I was six or seven years old then, and construction was this weird miracle process that I experienced first hand through each stage as I wandered that construction site on a daily basis.

A small U.S. town in the 70’s was such a wonderful place and time to grow up, from that perspective. No one cared that a child, or a group of children, wandered onto construction sites. They’d even answer questions if you asked nice, before shoeing you away so they could get back to work. I cut my architectural teeth that way, on dozens of construction sites. Wandering into construction wherever I stumbled across it, fascinated by the simple act of creation that was involved in them. Wandering around in finished buildings and then going places that aren’t finished for public occupancy so that I could see how all the pieces went together to form the seamless facade that is what the public sees.

Programming is invisible, like the structure hidden behind the finish in your home. Programming is best when you never notice it. If you notice the programming, it is like noticing that whoever taped and floated the wallboard for your office wall wasn’t very good at their job. You have to know where to look in order to find the programs that run everything on the web. Right click on any window in your browser, for example, and pick view page source. You’ll get a nearly incomprehensible page of text characters as a result. Incomprehensible, if you are a layman.

If you work with HTML for awhile, something you will have had to do if you’ve written anything for the web and cared about how it looked, the text that is displayed becomes more comprehensible. You can seperate commands <text> from the rest of the content on the page simply by recognizing the characters that denote a command. If you’ve been working around websites for years like I have, you become convinced you know more about the subject of putting stuff on the internet than you actually do. Until you have to do the work to get it there, and there is no one willing to talk to you about it.

So if you find yourself in the predicament I’m describing, trying to figure out how to get stuff to show up on the internet, this guide is for you. Welcome. Let’s learn stuff together, eh? The first thing you want to decide is where to host your website. That’s your first job.

Most cheapskates will be tempted to host their own website. My advice is don’t. Don’t do it unless you are a programmer and you have enough cash to pay for all of the hardware you will need (and if you are that person, you won’t be reading this in the first place) That is my best advice right there. If you aren’t a programmer then hosting your own website is ultimately only going to create another digital zombie that can be used to attack other websites, or it will serve as a ransom target. A liability that will cost you more than the hosting fees will cost you. So don’t be John Podesta. Be smart, like Hillary Clinton. What, Hillary Clinton isn’t smart? She didn’t get caught, did she? I rest my case. Hire people to do the stuff you don’t know how to do, and pay them well to do it. You’ll thank me for that advice, if you follow it.

You also don’t want to necessarily go with the cheapest web host. Do you want the cheapest doctor you can find, or the one that knows enough to help you and not hurt you? There are several websites that can help with this task, selecting a web host. Who is hosting this? is one of those sites. Look around to see what the people in your line of work are doing. See what other comparable web hosts are offering and for what price. Go with someone who can help you in a crisis, not just someone who has the cheapest price. You can even buy space from a web host so you can act as a web host. This is what the Wife is doing, she’s just not making any money off of me when she does it.

So you have your web host selected? Good.

A web host provides the software you will be using to create your website. Everything to do with computers requires software, but the internet is everywhere and in everything these days, so it is easy to forget that there is code behind all this interconnectivity that we enjoy today. Your web host will have software it utilizes, and that software is most likely going to be Apache. As an open source evangelist, I wouldn’t suggest you run anything else on your web servers.

ASF 20th Anniversary – Mar 26, 2019

Cpanel is the most common graphical user interface for Apache once you get beyond the command line; and frankly, why use the command line if you don’t have to? Cpanel is short for Control Panel. If I have to tell you what a Control Panel is then you haven’t been doing this long enough. Take some basic computer classes, or just pay SquareSpace for their services. They’ll happily hold your hand, given how much you will be paying them. If you don’t have the money for Squarespace (it isn’t cheap) and can manage without their very useful 24/7 helpline, but still want to be using a super simple interface, there is Wix.com and Weebly.com. Squarespace isn’t paying me a dime to recommend them, therefore I’ll go the distance and give you a few more options.

Going hand in hand with Cpanel is WHM, the WebHost Manager (this will be important in the next section) Their user documentation is here and here. If your web host uses Apache they are most likely going to be using Cpanel and WHM as the control panel and manager for the hosting service. Once you have signed up with a web host you are now dabbling in web hosting, at least vicariously. WHM is your best friend when managing a web host. You should probably get to know your new best friend better.

If your site is new on the web hosting service, it is a pretty simple thing to just pick the software you want to use from the software list that your web host should offer (softaculous on our web host) WordPress is very likely to be one of them. Install that software and start playing around. You’ll break things a few times, but that’s great. You want to break things when you are learning new stuff. Use the installer to uninstall, and start over. Have fun! If your site is a new site with a new web host then congratulations, you’re done. If you are like me, borrowing space on someone else’s hosting site, then you are only getting started. Read on for the dreaded WHM and the effective separation of your shit from their shit.

Still Being Sent to Blogspot?

I just figured out that the domain forwarding I set up in blogger is failing for some reason now in mobile interfaces. this post link //ranthonysteele.blogspot.com/2018/12/bye-blogger.html should take you to the article on this website that corresponds to that article on Blogger (you’ll get a generic landing page since there isn’t an article of that name) In any mobile browser you use to open it, you will probably be taken to the article as it still exists on blogspot.com. I could have sworn I checked the forwarder on my phone after I first made the switch. WTF?

Weirdly, you can be redirected to the correct address by trying to navigate from inside the blogspot address. I have no idea why it even goes there at all in the first place. I’m guessing it’s a mobile tag that the code in the blogspot theme that redirects here doesn’t know how to handle. I’ll have to troubleshoot it eventually, I guess. Doesn’t really matter. It kicked me into copying new articles to the old address, a task I had been neglecting. I so often re-edit an article after it is first published that it becomes tedious making manual backups that no-one is supposed to see in the first place. Knowing people will possibly see the blog not being updated any longer? OK, that’s enough motivation.

Facebook.

Something Blogger Could Never Do

Showing off. That’s all I’m doing here.

What would Blogger never do? It would never let me write and edit a blog entry from different locations successfully. Sequentially. Oh, you could write different articles from different locations, just not the same one and not have it overwrite the other one you wrote somewhere else. Take that, Blogger!

Now I’m editing the same article on the laptop that I created on the phone! Here, I’ll even throw in a random image of my dog. Look at that! a picture! I wonder if it will stay here when I edit it on the desktop?

Looky there! The photo is still there, and the original post is still there, and I can add stuff on the desktop too! Back to the phone now.

I can log into the editing interface on the mobile version of WordPress, and I can use the edit functions right in Chrome without having to grow/shrink the page to be able to see the buttons. It works much the same way that Mastodon does on a mobile platform. Seamless. No feeling of being in a poorly scaled room, trying to sit in chairs made for the butts of some other species.

Now I just need to figure out how to get the theme to do what I want. I won’t be holding my breath on that score. My batting average when it comes to getting myself comfortable with code is appalling, and I can’t seem to make heads or tails of what themes control and how to change them. Stay tuned.

Why you shouldn’t just willy-nilly create custom blocks and stick them in your articles. At least Gutenberg now distinguishes between varying separator types. That’s a nice step. Or is it the fact I’ve changed the theme again? I’ll have to check that.