Tenseg

Getting to know Statamic

2024-12-07T12:00:00-06:00

The recent unrest in the WordPress community has got us exploring other ways of building websites. We’ve been building sites with WordPress since the late 2000’s, so this is a big deal. We did try building a few sites with Jekyll, looking for an easy way to build static websites, but while Jekyll had some real benefits, it never seemed like something we could ship for clients.

A few months ago someone suggested we look at Statamic. We had not heard of Statamic nor Laravel, upon which it is built. (Yes, we’ve been living under a WordPress rock.) Laravel is a PHP framework that is much more general than WordPress, a way to build almost any web app. Laravel is highly regarded, growing, and considered quite securly architected. Statamic is a content management system built as a Laravel app.

At a glance, the Statamic control panel looks an awful lot like the WordPress dashboard. Upon deeper inspection it turns out to be both less chaotic and more capable out of the box. Statamic includes the equivalent of WordPress custom post types, custom fields, and forms while maintaining a clear and approachable interface. Where WordPress has the feel of a system cobbled together over the years with little sense of where it would end up and not much attention to internal consistency, Statamic feels like it knew what it wanted to be before it was created. Deep down, Statamic is nothing like WordPress even though any casual WordPress user would feel totally comfortable using it.

For the developer, Statamic is a joy. There is a massive learning curve, to be sure. Although both WordPress and Statamic run on PHP, the two could not be more different. Getting to know Statamic means learning Laravel, and that’s a whole new universe for some of us. But actually, we have seen way less PHP while building a Statamic site than we typically see building a WordPress site. Templates are built using an engine called Antlers that lives right in your HTML files in a way that feels much more harmonious than PHP. In fact, if you go with the flow and also adopt Tailwind CSS for your templates, then you will also hardly see any CSS at all. We have built two sites already in Statamic and hardly had to touch any PHP beyond a few config files. It is remarkable, a throwback to the days when we could just write pages in HTML.

Custom post types, custom fields, and forms all feel like awkward bolt-ons in WordPress, but in Statamic they share one common workflow of blueprints that display fields or fieldsets. A custom post type is just a collection of entries that shares a particular blueprint. A form is also just a blueprint bringing together and arrangement of fields. Custom fields are simply fields, which can be used in any blueprint. So you build specialized collections and forms (and even global variables for the site) with the same set of tools. In fact, there is nothing special or privilaged about the default collections, they use exactly the same blueprints and fields. With Statamic there is no friction if you need a particular piece of data in a collection, just add the field to the blueprint.

By default, Statamic requires no database. All data is stored in plain files. The beauty of this is that everything from the content of your pages to the blueprints and fields to the templates and configuration is just files in the filesystem ready to be managed in a source control system like Git. If you really want a database, the tools for keeping elements in a database are available, but for most sites they are not necessary. Statamic benefits from the terrific caching Laravel provides to keep sites speedy without the database. Statamic even provides a static site generator that can spin the whole site out as static files that do not even require PHP to be presented.

Although you would not know it, because the design is nearly identical to what we had in place last week, this week we rolled out a new version of our website being generated by Statamic. The site has been rebuilt using Tailwind CSS classes as well. Our experience recreating this site has taught us a lot about Statamic, Laravel, and Tailwind, and we have a lot more to learn. But the biggest lesson is that building sites this way feels really good. We feel silmultaneously “closer to the metal,” able to focus on HTML, and free of constraints, easily adding the elements we need to the user experience to make the site easy to edit and manage.

If you are not a developer, then you may have to stick with WordPress, as we note, there is a learning curve to picking up Statamic and it does require that you be comfortable with code and the command line. If you are a developer interested in an alternative to WordPress, Statamic is worth your time. If you are a developer new to building a website, there few places better to start than Statamic.

Repairing the Chain of Trust

2021-10-11T12:00:00-05:00

Some of you may have heard from your customers or website users that your site is no longer accessible and instead is showing a message warning that the site is “not private” or that a “secure connection” cannot be established. We wanted to explain what is happening and how your users can resolve the problem.

The web has been with us for nearly 30 years, and one of the big changes behind the scenes on websites has been how we verify that a site is what we think it is. As the web emerged in 1993 there was no effort to demonstrate that trust, we just believed what we saw. But over the last ten years there has been a shift to “secure” the web using certificates, facilitated by the emergence of free and inexpensive certificates from trustworthy sources. We use the most common of those free sources with our client sites: Let’s Encrypt.

At the end of September 2021 an old “root certificate” for Let’s Encrypt expired. Let’s Encrypt had long since moved on to a new copy of that root certificate and most modern devices have since had software updates that included this new root certificate. But “most” is not “all” and some older devices have not been updated. These devices don’t know about the new Let’s Encrypt root certificate and, as a consequence, are not aware that they can trust other Let’s Encrypt certificates like the ones on your site.

You and we can do little to fix this problem. Indeed, we may not even experience it if our browsers have been updated recently enough. If you do field a complaint of this sort, though, the person who is experiencing the problem can fix it by installing the new Let’s Encrypt root certificate manually. In order to help them do this we have prepared a brief “how-to” post that they can follow. Please direct anyone who needs this information to our “Installing the new Let’s Encrypt root certificate” post. Make sure they use the insecure HTTP version of this link since they will not be able to access the regular secure version of our website: http://www.tenseg.net/install-cert/.

Installing the new Let’s Encrypt root certificate

2021-10-10T12:00:00-05:00

All of our websites (and many others across the web) use certificates for encrypted connections issued by Let’s Encrypt. On 30 September 2021 the root certificate for Let’s Encrypt, which validates every certificate issued by them, expired. Most computers and other devices have automatically been updated to support the new chain of certificate trust provided by Let’s Encrypt.

However, older devices may not receive this update. If you have trouble accessing a website we manage, please follow these instructions to manually install the new certificate chain. Unfortunately we cannot do this for you. Each computer that did not automatically install the updated certificate will have to have the certificate manually installed.

macOS

Your older version of macOS or iOS is probably holding onto the expired R3 > DST Root CA X3 certificate chain even though it should no longer be used. For older macOS systems not updated by Apple:

Download the ISRG Root X1 certificate file from http://x1.i.lencr.org/
Open the Keychain Access app and drag the “ISRG Root X1” certificate file you just downloaded into the System keychain in Keychain Access.
Find the ISRG Root X1 certificate in the System keychain and double click on it. Open the Trust option in that window and change “Use System Defaults” to “Always Trust”. If you are asked for your password, please enter it and close this window.

Windows PCs

On older Windows with an outdated trust store you can manually install the “ISRG Root X1” certificate:

Browse to http://x1.i.lencr.org/ in order to download the file for ISRG Root X1 (your browser may warn about the file type and you may need to click “Keep” to save the file).
Open the file, click “Install Certificate…”, Choose default option “automatically select…”, Next, and Finish.
Reboot your computer.

[Note, these instructions are from Certify the Web, but since their page is secure and thus inaccessible to the people who most need it, we are repeating them here.]

Checking Old Sites on 404

2021-08-05T12:00:00-05:00

We recently ran into the situation where a page on a client’s site was returning 404 (File Not Found) because the page really lives in the archived copy of the site, but had the URL as if it were on the current website. It was easy enough to update the URL in page content where we referred to it. However, in this instance the docunent that was linked was a PDF that had links in it that were broken in the same way. Editing the PDF was not something we had the source material to do, nor wanted to do as it was part of the archived site. So we had to come up with an automatic solution.

We went about looking into how WordPress could redirect 404 errors over to the archived site if the requested path was not found on the current site, but was found on the archived site. The result is the TG 404 Site Checker plugin. Since it is a simple enough plugin we thought that we’d make it available to anyone else who may find it useful. Configuration instructions are in the readme file. Feel free to use this plugin. If you find any problems or want to suggest any features, just submit an issue.

Bottom line, we had a problem on a client’s site, and made a fix that is generic enough we think it may help others. So, here is the plugin we wrote with the fix. Generally, whenever we can we like writing plugins that are more generic, because that way we can use them on all our client websites as needed. TG 404 Site Checker is a simple plugin that fills a very real need, and has a simple configuration. We hope you find it as useful as we do.

Moving from Master to Main in Git

2020-08-06T12:00:00-05:00

Following the recent unrest around race relations after the death of George Floyd one of the lesser-known movements has been to move Git repositories from using master as the default branch to something else, most commonly main. We took the time to transition all of our projects’ repos in this manner. The process we took, which was based on this article, is documented here for anyone else (including our future selves) who want to do the same.

Transitioning a Repository

To start this transition on the local repository on your computer you should make sure to stash any uncommited changes if there are any, then run the following at the command line in your project’s folder and take note of what remotes the repository has for later use:

git remote -v

Then actually move the master branch, here to main:

git branch -m master main

Now it is time to push this new branch to remotes, so for each remote you took note of:

git push -u <remote_name> main

Once the branch is up on the remotes you’ll need to set the new branch as the Main branch. This is in different places on different sites, here are the ones we’ve used:

For Github: Under Settings for a repo choose Branches and change the Default branch
For Bitbucket: Under Repository settings choose Repository details, then open the Advanced section and change the Main branch
For Gitea: Under Settings for a repo choose Branches and change the Default Branch

Back in your local repository you’ll need to delete the master branch from each remote:

git push <remote_name> --delete master

And finally set your head to the appropriate remote, usually origin, as well as pop your stashed chagnes if there were any:

git remote set-head origin -a

Changing Repositories on Other Computers

Once you have transitioned the repository on one computer, all other computers which have cloned it will need to run through the following:

git fetch --all
git remote set-head origin -a
git branch --set-upstream-to origin/main
git branch -m master main
git pull

Changing the Default Branch Name Used for New Repositories

Now that you’ve taken the time to transition existing repositories you’ll want to always use the new name for future projects as well. Unfortunately Git does not have a simple setting to change, there seemed to be one but it didn’t seem to work. So instead you’ll want to make a custom repository template to use.

The first trick here is figuring out where Git is installed. On Macs you may have used Homebrew to install Git. In that case the base tremplate files would be found at /usr/local/share/git-core/templates. The next step will be determining where you want to store your custom template files. I chose ~/.config/git/template/ as my location, but anywhere in your user account would work. Then run the following, replacing the placeholders as needed:

cp -r <system_git_template> <user_git_template>
echo 'ref: refs/heads/main' > <user_git_template>HEAD
git config --global init.templateDir <user_git_template>

When you run git init Git will say it is reinitializing the repository even though it is a brand new repository. This is a side-effect of the reality that your template has a HEAD file in it. Don’t worry about this. But now any new Git repository you make will have the main branch from the start.

Zoom Zero-Day Flaw

2019-07-09T12:00:00-05:00

Yesterday a report came out describing a zero-day flaw in the Mac client for the popular online meeting service Zoom. The report is quite technical, but describes some very serious security flaws in the client software. I’m going to unpack the basics here, and most importantly give you a (fairly) straightforward way to secure your Mac if you have Zoom installed. I highly encourage everyone to follow these steps as soon as possible.

The Flaw

The core of the security flaw is that a malicious website can trigger you to enter a Zoom meeting with video and audio automatically enabled. This is acheived through the the website calling out to a webserver on your Mac that Zoom installed, which incidentally remains even if you uninstall Zoom, and will reinstall Zoom if you ask to join a meeting, all without asking you for permission. The launching of Zoom through this server is acheived through a specially-crafted image, which they use to bypass sandbox security implemented by browsers to try and stop this sort of thing. This was reported to Zoom back in March, and by yesterday, the public disclosure deadline, Zoom still hadn’t fully fixed the problems (they had made one fix, but a workaround was discovered). You can read all the technical details at the report linked earlier in this post.

Instructions for how to Protect Your Mac

To secure your Mac against this zero-day you need to run a series of commands at the command-line on your Mac. You do this using the Terminal application, found in /Applications/Utilities. Copy and paste each of these commands exactly as they are below (with the exception of the one where you enter the PID unique to your Mac), hitting return after each one. I may get around to providing a simple tool anyone can run to with one-click perform these actions, but this is serious enough that getting them documented and out to folks is far higher of a priority.

Disable Zoom’s ability to turn on video by default:

defaults write ~/Library/Preferences/us.zoom.config.plist ZDisableVideo 1


Check for the hidden Zoom webserver:

>```bash
lsof -i :19421

If this command returns any output then the server is running. In that case, take note of the number in the PID column.

Kill the server:

kill -9 (PID number from the previous step)


Remove the server's files:

>```bash
rm -rf ~/.zoomus

Create a new file in its place:

touch ~/.zoomus


Change its permissions so that Zoom cannot overwrite it and add the server back:

>```bash
chmod 000 ~/.zoomus

You will need to perform these steps in every user account on your Mac that you have used Zoom in.

Side-Effects

After performing these steps your Mac will be immune to this zero-day flaw. Unfortunately, Zoom will also no longer act quite as it has in the past. Specifically:

You will need to manually turn on video in all meetings.
The Zoom links to enter meetings will no longer work. Instead you’ll have to launch Zoom yourself, ask to join a meeting, and enter in the meeting id.
Zoom will no longer auto-update. Instead, every so often make sure to redownload the Zoom app from their website.

Once this issue is confirmed fixed, and if you ever again trust Zoom’s full install, then you should only need to delete the file you created and Zoom will set itself up as intended again:

rm .zoomus

I strongly urge everyone that has ever used Zoom on their Mac to perform these steps. Yes, it will make joining a meeting more difficult, but it will make it so that you can’t unknowingly join a meeting with video enabled.

Update 10 July 2019 7 pm Central Time

Apple has pushed an update to the Malware Removal Tool built into macOS that removes the local Zoom web server from all Macs automatically.

Update 10 July 2019 3:40 pm Central Time

Zoom did release an update that removes the local server overnight last night. This version should not have the zero-day flaw in it.

Update 9 July 2019 4:20 pm Central Time

Zoom has announced that they plan to release an update by midnight tonight that removes the local web server.

Update 9 July 2019 3:40 pm Central Time

I noticed that my Mac’s Zoom client was slightly out of date. When I went to download the latest version what they give you is an installer package. That is the first red flag, as very few developers need more than drag and drop to install their apps. I always open installer packages first with Suspicious Package, to examine what they’ll do before installing them. Now even more red flags appeared… The package runs a script upon opening, before you can even intervene. Now, this usually is just checking that you meet system requirements, but Zoom’s installer is messing with the Dock and doing a bunch of other things, some of which may be nefarious, I haven’t deciphered the script entirely yet. But even more troubling, the installer package does not have any files it installs, and the scripts in the package include what appears to be the file structure of a kernel extension and web browser plugin, with almost no sign of a regular Mac app other than an entitlements file. But that isn’t how it should be. The scripts should just be scripts (preinstall, postinstall, and Distribution), and regular installer packages would put the files they install into the regular installation mechanism, which would appear as files in the package. The app itself is in the scripts folder in the zm.7z archive. You can use the 7z command (which can be installed with brew install p7zip) to extract the app. I would recommend doing this rather than running the installer package. I think we’re starting to see why Zoom hasn’t fixed these flaws yet. It seems possible that they need to do a significant rearchitecting of the entire app and service to fix these problems. Zoom was such a good service… These flaws, and this unorthodox download, very much hurt their reputation in my book.

Concerns About the State of App Store Review

2019-02-20T12:00:00-06:00

As an interesting sidebar to our post about SubCalc 3’s release today that will be of interest to fellow developers…

In releasing SubCalc 3 to the App Store we accidentally had a severe bug in it that caused the app to show just a white screen when opened. This was a side-effect of our build process not quite working when preparing the app for submission to the App Store, which is why we didn’t catch it. Shortly after we found out we pulled SubCalc 3.0.0 from the U.S. App Store (because, even with a call to developer support, we couldn’t get Apple to reject the update and leave the working 2.0.1 on the store). We have since fixed the problem and modified our procedures to catch such issues in the future. Always export for ad-hoc distribution the archived app you’re about to submit to the App Store. Install it to your device to be sure that it works as expected. The problem came down to two basic things we failed to do in our build phase script that builds the React app:

We were not quoting paths that were used in our build-react-app.sh run script build phase. This meant that we were using the wrong paths for where to write out the built React app to. Instead of ending up in the proper product it was in a “mirror” version within the source code when archiving.
We had been using ${BUILT_PRODUCTS_DIR} to access the built product. This failed to give us the product path when being run while archiving the app for App Store submission. Instead what is stable across all build configurations is to use ${CONFIGURATION_BUILD_DIR}.

The thing is, this is among the kind of issues we expect the App Store’s review team to flag for rejecting updates. They let our initial 3.0.0 update out on to the App Store. This means that in their review process they evidently didn’t even bother trying to run our app. I’m not sure if I’m more scared of this as a developer or as a user. How can Apple be 100% sure that apps aren’t doing bad things if they don’t even run them? This feels like a potential security problem waiting to happen, since as users we trust that apps provided from the iOS and Mac App Stores are safe and operate as intended.

Have any other developers of apps for Apple’s devices had a similar experience? I’m all for the speedier (about 3/4 of a day for both SubCalc 3.0.0 and 3.0.1) app review times, or so I thought. But if this is allowing outright broken apps at best, and malicous apps at worst, on to the App Stores then this is a real problem. Users deserve confidence in the software they install, and because I’m also a developer I am especially concious of this as a user. Beyond my own practice as a developer, this experience makes me worried about the overall quality of the apps I use on my devices that ostensibly are coming from a secure and trusted source.

SubCalc 3 Released

2019-02-20T12:00:00-06:00

Today we are pleased to announce that SubCalc, the Subcaucus Calculator, has been updated to version 3. Those of you with SubCalc on your iPhone or iPad should recieve the update shortly if you have app auto-updating on, and everyone else can install it from the App Store. As before, a web app version is also available for those without iPhones or iPads, or those who need to use SubCalc on desktops. This is a major new version that we rewrote and redesigned from the ground up. This version introduces numerous new features:

Save multiple snapshots of meetings
Duplicate a meeting
Sort the subcaucus name and members columns (thanks CT for the suggestion)
Hide the delegates column (thanks CT for the suggestion)
Share snapshots as text, code, spreadsheet, or a link to the iOS share sheet
Import snapshots via link either by viewing in Safari or using the Paste clipboard option in the app
More detailed explanations of the numbers this calculator gives you
Quickly reset the members column for the next walk (thanks CT for the suggestion)
Quickly remove empty rows

We have also made SubCalc available as a public open source project on Github. Both the iOS app, and the web app at its core, are open source. We did this partly so that people can audit the code that performs the mathematical operations to trust the results it gives more. Feel free to participate in the future development of SubCalc, even if only by opening issues for bugs you find or new features you desire.

We hope you enjoy the refreshed SubCalc. Please don’t hesitate to send us feedback either [email protected]">in email or at Github if you find bugs or have feature requests.

Losing Your Head

2018-10-25T12:00:00-05:00

Today I am giving a brief presentation at our Minneapolis St. Paul WordPress User Group about our experiment with “headless WordPress.” We recently built a site that needed to stay super-simple for users while incorporating a back end for managing images and comments. We also wanted the site to eventually turn into a static website with no back end at all. Our solution was to build the front end in React and use the WordPress API to provide a connection to a WordPress install that could manage the incoming images and comments.

My slides for the presentation tell the basic story. Since the demo is not really available online, instead you can visit the Sharing Rob site that inspired this solution (please don’t add anything there unless you knew Rob). Another resource to explore might be this introduction to headless WordPress with React.

One of the really nice features of this solution is that as soon as we want to “freeze” the site and stop further contributions, all we have to do is put a static version of the file returned by our API call onto the website. Once we do that, we can remove every trace of WordPress (except the static uploaded image files) and be left with a site that requires no updates or maintenance.

Signing Your Work

2018-08-27T12:00:00-05:00

Git has the notion of defined authorship for commits and tags. This is done at either a repository or global level, using the git config command. This allows Git, and in turn sites like Github, to recognize who authored what changes to code. But config settings in plain text only go so far. Much like (regular) email, really anyone can impersonate you. Nothing can stop someone from putting your name and email in their Git config. All of a sudden you’d see commits that “you” authored which you know were in fact not you.

There is a way to get around this issue, and confirm authentic authorship, should you want a more certain way of letting people know that you authored code in certain commits. You can use a GPG/PGP key to digitally sign commits and tags. This means that though anyone could impersonate your name and email, someone could only digitally sign commits as you if they got ahold of your private key, a much larger challenge than merely editing a text file.

I have set this up on my Macs, and wanted to document the process here for future reference and in case anyone else wants this higher bar of certainty on their Git commits. The following sections describe the necessary, and optional, steps to getting this set up.

Git Version

Only versions of Git >= 2 have the GPG signing features. macOS High Sierra should have a sufficient version, but I recommend installing Git via Homebrew anyway (brew install git) to always have the latest release if you’re a serious user of Git. An advantage of the Homebrew Git install is that it comes with the git-prompt script, which allows you to show Git info in your command line prompt. Additionally, this will put the version of Git you’re using within the same paths as the GPG software.

GPG Tools

While you can install GPG software on the Mac via Homebrew, I recommend installing the free GPG Suite. A word of caution, you should customize the install and uncheck the GPGMail plugin for Apple’s Mail app. Even if you intend to digitally sign or encrypt email (which I don’t) you can still use the systemwide Services to sign or encrypt email contents, and the plugin has caused problems with composing mail for me in the past.

After the install finishes it should automatically open the GPG Keychain app and ask you to generate your GPG key. If you already have a key you can cancel this and import your existing key. But I’m assuming you don’t have a key for the purposes of this post. As soon as it has generated your key it should open the main window. At this time I highly recommend exporting your public/secret keypair to a secure location for safekeeping (but more on that, too, later).

It is worth going to System Preferences and opening the newly added GPG Suite prefpane. You should check that your key is the default, and I find it safe enough to let it store key passwords in the macOS Keychain (but that one is up to you). You can change any of these preferences to your liking.

gitconfig

You’ll need to add some information to your global gitconfig file in order to tell Git about GPG. Open that file and add the following:

[commit]
 gpgsign = true
[gpg]
 program = /usr/local/MacGPG2/bin/gpg
[user]
 signingkey = { your key id, found in Details drawer of GPG Keychain }

You should now be able to commit to any repo and that commit will be digitally signed using your GPG key. In order to confirm that the commits are now being signed use git log --show-signature to have the log also display signature information.

gpg.conf

While Git from the command line will now be able to sign all commits and tags, you need to add one line to your ~/.gnupg/gpg.conf file to allow IDEs (like Xcode) to do so. Just add no-tty to the bottom of the file and save it. Now Xcode will no longer only give you a fatal error when trying to commit.

GPG and Github

Now that you are digitally signing your commits you need to tell Github about your key so it can verify commit authenticity. To do so go into your Github settings, and choose SSH and GPG keys. That’s right, the same place you’ve come to add SSH keys you now go to add your GPG key. You can export your public key, open the file in a text editor, and copy the key block from there. From here on out, any signed commits of yours will show a green “Verified” label, both to you and others on the project.

Note that, unfortunately, Bitbucket Cloud does not currently support showing GPG and signed commit information.

Publishing your Key

It is a good idea, though optional, to publish your key. GPG Keychain can do this by sending the key to the network of public keyservers using the option for it under the Key menu. You can also simply put your public key block somewhere on your website. Facebook also allows you to add your public key to the Contact Information section of your profile. You can, of course, also email it to people or send it along like any other attatchment using any service.

Since trust is behind the strength of GPG keys, it is important that your public key is accessible to others. Just make sure that you keep the secret key close and secure. Mine is only in the keyrings on the Macs I use, and one export file that is encrypted and secured in a safe place.

keybase.io

Recently I found the Keybase website and software. This is a system that gives you a public profile (link is to my own profile), and lets you publish your GPG key, and verified ownerships of other online profiles and websites. Though totally unnecessary to use GPG to sign Git commits, Keybase can be a home for verified identities and sharing your GPG key. Further, it provides truly end-to-end encrypted storage and chat for yourself, teams, and between individuals, as well as digitally signed public folders. All based on the GPG key technology. Keybase actually has its own entire Mac app and command line interface, but you still need the regular GPG software to use your key with Git (and having it makes sense anyway so the key is usable in normal ways). So, Keybase is a collection of tools to help connect people who have GPG keys.

Conclusion

This post gives the briefest overview of how to set up Git to digitally sign Git commits. You can look through Git docs to learn more, including how to sign tags. If you follow the first sections you’ll have a key, so it suggests further uses regarding sharing that key. GPG is still quite complex, so won’t be used by that many who aren’t very good with technology (though Keybase’s hope is to change that) at this time. But it is a useful thing to know about and use, if not for all possible uses, so that if you have a more important need of it you’ve already begun learning.

Using a Private Git Server

2018-07-28T12:00:00-05:00

While services like Github and Bitbucket are invaluable to our work as web and software developers, they are run by other companies, and as such aren’t in our direct control. They may go down at inconvieient times, or be buggy in other ways. You may also find yourself doing projects that you don’t want to actually put in the clutches of external entities at all. As a supplement to these (or similar services) you may want to consider running your own self-hosted (and potentially completely private) Git Server. I recently set up just this. I thought that it would be worth describing what we have going in case it would help anyone else.

The first thing that you’ll need is some computer to run as the server. In some cases a Raspberry Pi may do, but we were offered an old Mac Mini by family, and also have more complex uses for an internal server (like running Plex), so went with a full-fledged Mac instead. It is that configuraton that I’ll be discussing here. My first bit of advice is to clean install whatever the latest version of macOS that runs on the computer is, in our case that was macOS High Sierra. The reason to do this is to ensure that when you build your server it is as clean as it can be. We don’t want leftover cruft from when the Mac was being used as an everyday computer.

When you are setting up the fresh install I recommend first creating a dedicated apple account as the only admin user, and setting a strong password on it. You will rarely actually be in this account directly. Create a separate standard user, I named ours server, that is set to log in automatically. This is the account that will actually run the Git server. You’ll also want to ensure that the server starts up automatically after a power faiilure, and that it is automatically updating at least security updates. I also turned on screen sharing, file sharing, and remote login so we could manage the server from our own Macs, with the server itself running completely headless.

There are a number of projects that are Github clones, I chose Gitea to run as our internal Git server. Installing Gitea could not be easier, since it can be done via Homebrew:

brew tap go-gitea/gitea
brew install gitea

You will also need MySQL installed. Then you can go and create a user and database for Gitea to use. After that just run

gitea web

to start the server. It should tell you what the URL is to access the server, going there will take you to the Gitea setup screen. Basically, enter the database information and a few other details and you’ll be all set. Gitea should provide you with helpful hints as a brand new admin user.

By default Gitea is using /usr/local/bin as its home directory. So I recommend changing that to something within the server user. We chose to make this a gitea folder in the server user’s home directory. To do this you need to simpy run Gitea specifying a custom path to its config file:

gitea web -config /Users/server/gitea/conf/app.ini

The file should be under custom/conf in /usr/local/bin right now, so just move the file to a conf folder in whatever folder you want Gitea to use for data. Open that file and you’ll see a number of other file paths specified. I sugest changing all of these to be subfolders of the folder that you’ve set for Gitea to use. You should also look at the config cheat sheet and set specific folders for all of the path settings the config file can have. For the most part these should be subfolders, except I would reccommend that logs go into a gitea subfolder of the user’s logs folder at ~/Library/Logs so that Console can be easily used to navigate logs. You should also set the URL and Port as appropriate for your environment.

The final step in setting up Gitea is to ensure that it runs at login (which is system startup if the user logs in automatically). Do this be creating a Launchd plist file for this service at ~/Library/LaunchAgents, maybe name it io.gitea.gitea.plist. The contents of this file should essentially be:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>KeepAlive</key>
 <true/>
 <key>WorkingDirectory</key>
 <string>/Users/server</string>
 <key>EnvironmentVariables</key>
 <dict>
  <key>GITEA_WORK_DIR</key>
  <string>/Users/server/gitea</string>
  <key>GITEA_CUSTOM</key>
  <string>/Users/server/gitea/conf</string>
  <key>HOME</key>
  <string>/Users/server</string>
 </dict>
 <key>StandardOutPath</key>
 <string>/Users/server/Library/Logs/gitea/launchd.log</string>
 <key>StandardErrorPath</key>
 <string>/Users/server/Library/Logs/gitea/launchd_error.log</string>
 <key>ProgramArguments</key>
 <array>
  <string>sh</string>
  <string>-c</string>
  <string>/usr/local/bin/gitea web -config /Users/server/gitea/conf/app.ini</string>
 </array>
 <key>UserName</key>
 <string>server</string>
 <key>RunAtLoad</key>
 <true/>
 <key>Label</key>
 <string>io.gitea.gitea</string>
</dict>
</plist>

Pay attention to the paths in this file to make sure that you change them from this example as needed. To start the service run:

launchctl load /Users/server/Library/LaunchAgents/io.gitea.gitea.plist

From here on out is should be kept running by macOS, and started on user login. At this point you have your own Git server running. You should explore it as much as you’d like, and start playing with it.

To use the second server, just add it like normal to your repo with git remote add, but remember that its name needs to be something other than origin. To fully integrate this new server as a backup of your primary remote you should push to it anytime that you push to the primary remote. Git makes this quite easy. A single remote can have more than one URL to use when pushing, so you set up the remote like so:

git remote set-url --add --push origin [email protected]:test/my-project.git

You actually need to run this same command for the original remote URL to keep pushing to it as well. From here on out whenever you push you will be pushing to both your prinary and internal remotes. No need to worry about keeping your internal remote current. You can only pull from one remote at a time, and should only regularly do this from your primary remote, but you should still set up your internal remote the traditional way so you can pull from it if needed. The next time Github or Bitbucket go down, or even just your local internet connection, you will be able to continue pushing as normal so your partners can get your changes and you have the peace of mind to know that your changes aren’t on just one machine.

Changing the email WordPress sends administrators when passwords change

2018-07-15T12:00:00-05:00

WordPress offers two little-known hooks for changing the email WordPress sends administrators and users when passwords are changed. These two filters (wp_password_change_notification and password_change_email) behave a little differently from one another. The biggest factor that caught me by surprise was the fact that wp_password_change_notification does not work at all when activated on a subsite of a multisite network (at least when that network is using subdirectories to distinguish sites).

Let’s define a small plugin called passworder to demonstrate how this filter can be used. Here is the passworder.php file that defines the plugin.

&lt;?php
/*
 * Plugin Name: Passworder
 * Description: Modifies the email that goes out when passwords are changed.
 */

function password_change_email_admin( $email, $user, $blogname ) {
    $message = sprintf( __( 'Dear admin: password changed for %s: %s %s' ),
        $user->display_name,
        $user->ID,
        $user->user_login
 ) . "\r\n";
    error_log( $message );
    $email['message'] = $message;
    return $email;
}
add_filter( 'wp_password_change_notification_email', 'password_change_email_admin', 10, 3 );

Note that the wp_password_change_notification_email filter will not work at all unless it is network activated. This is because the whole password recovery process is executed at the network level and not within the bounds of a specific subsite. In this case, if the plugin were activated on a subsite, it would never be loaded and thus the filter would never be called.

This is not the case for the other filter, password_change_email, designed to send mail to the user when an admin changes their password using the profile. In this case the filter should be in a plugin activated on the subsite, not at the network level.

LBF Container

2018-03-08T12:00:00-06:00

A large part of my work these days is writing plugins and themes for WordPress. I use a tool called Local by Flywheel to run copies of client sites, and other experimental sandbox sites, for development purposes locally on my Mac. That way I can mess around as much as I need to without compromising the actual websites. Local has a somewhat unintuitive feature to open a (fake, since it is just Docker containers) SSH connection to the sites it runs locally. You access it from the contextual menu of sites in the main window. This gets old fast when you have a dozen or more windows open on your desktop, and it may be that Local is even in another desktop space altogether, behind yet more windows. That is just the reality of software/web development, lots of windows, regardless how organized you are. Usually up front in my development environments is my code editor, and most advanced code editors these days (including the one I use for web development, Visual Studio Code) have integrated terminals in their single window per project interfaces. So, all in all, digging around for a window just to launch a different Terminal and copy the command it runs to enter the Local site’s “SSH” in the integrated terminal was getting really annoying.

So, I thought it could be done better. Between last night and this morning I’ve put together my response to this inconvieient arrangement, LBF Container. This shell script can be called from any folder that is part of a Local site and it will drop you right into that site’s bash prompt. No getting lost trying to find Local’s window. No leaving your work environment whatsoever, in fact. It is somewhat blissfull being able to just type a simple command in the integrated terminal and end up with the same thing that used to take a few steps and digging around my Mac. I thought that others may be interested in this script as well, which is why I provide you with access to it. Let me know if this is useful to you, I’d love to hear your feedback.

Git Commit Info in your App

2017-08-03T12:00:00-05:00

For a while now we have been computing the build number for our iOS apps from the Git commit that the code was at when the project was compiled. This is done using a custom Run Script Build Phase in Xcode. We have recently expanded upon simply rewriting CFBundleVersion in the Info.plist to be that number, to also write out everything we’d need to know in order to know the current branch, the commit hash, and how many changes were made since the last commit (when shipping an app this really should be 0, but when developing it often will be some larger value).

The original version of this, which only wrote out the computed build number, came from a post on Tommy’s Domain. This only reported the build number, and also required manually setting what branch the count would be based on. As such, we have built upon this. We set out first to automatically set the branch based on the current branch, and along the way found ourselves deciding to actually write out a lot more information to the Info.plist as well.

All the code I’ll be discussing in the remainder of this post can be found at the very bottom, embedded from a Github Gist. Feel free to also discuss this post in comments on the Gist.

While you can write entire shell scripts directly in the Run Script Build Phase editor, this has a few pitfalls to be aware of, and so we don’t recommend it. The main pitfalls include a tiny editor space that does not have the autocompletion and other smarts we expect in Xcode, for each target you’ll need to copy and paste the script, which is unfriendly to further editing, and also the script contents is a part of the project file, so unfriendly to Git if ever you need to diff it.

Instead we reccommend writing a shorter shell (no pun intended) script as the Run Script Build Phase that itself calls an external script file that is in your project like any other source file. The build phase.sh script in the below Gist is what we use, based on a tip about Run Script Build Phases. You only really need the code starting with line 8 and on in your build phases, though take note that the shell to set this build phase to is bash. Also note that it expects the script itself to be in a scripts subfolder, but of course you can do whatever you’d like.

The git-commit-num-to-build-num.sh script in the below Gist is the script that actually does the fun stuff here. It first collects the information from the project directory (reporting it into the build log as it goes) and then writes that out to the Info.plist files. Since we write to the dSYM bundle as well, you’ll need to set your Debug Information Format build setting to DWARF with dSYM File for Debug builds as well as Release builds, which last I checked isn’t the Xcode default. This script also doesn’t need to be included in any of your targets, so when creating the new file you should uncheck all targets. You should also change the TSCommit key to something specific to your environment, as TS is simply Tenseg’s prefix.

If you’re wondering how to expose all this in your app we have also included example code for generating a versionString that you can use in an About view, logged string, or really anything you can dream up. That is in the version-string.swift file in the below Gist.

We hope that this may help you encode important details about your projects into your apps. Since the project is under Git already (if it isn’t, please stop reading this and put it under Git, then come back, also if it isn’t then this post really doesn’t apply to you) the targets might as well include Git-centric records that point back to the exact point in your project’s life they came from. If exposed to the user, or just included in bug and crash reports, having these details at your fingertips in each target can be very handy.

Please feel free to ask questions, leave comments, or just generally discuss in the comments section of this Gist.

Introducing HelloGameKitiOS

2017-07-20T12:00:00-05:00

Alex and I have been trying to write a turn-based game for iOS for quite some time. Last year we set it aside because we were seeing too many bugs in Apple’s Game Center and Apple’s documentation of turn-based games was severely lacking.

A few weeks ago I noticed that Apple released an example app called HelloGameKit last October. Unfortunately, this is a watchOS example, and Apple provided no instructions for how to actually get the code to work properly (Game Center games need to be registered with Apple, and we could not figure out which components needed what registration and capabilities in order to actually run properly on the watch).

Still, the Swift code was very helpful. We have now transformed this example into one that targets iOS instead of watchOS and released it as HelloGameKitiOS. We even included a few hints about how to actually get the game to run on your device (note, this will require an Apple developer account).

The “game” is pretty rudimentary. Players alternate turns and during their turn they can poke the other players. A turn simply captures the player’s id and a timestamp. The pokes disappear with each turn. But the game is sufficient to demonstrate how to communicate with the Game Center servers, how to update players of progress during a turn, and how to notice and trap errors coming from Game Center.

Now we will turn our attention back to the game we were working on last year. I hope this skeleton will help us resolve the Game Center issues we were encountering. And I hope that sharing this example may help others struggling with the same issues find some clues.

So please, if you are trying to get a turn-based game working with Swift, iOS, and Apple’s Game Center, give HelloGameKitiOS a look. If you have ideas about how to improve this example, feel free to communicate with us via the BitBucket issue tracker.

Docker and Visual Studio Code for Local WordPress Development

2017-02-24T12:00:00-06:00

On February 23rd Eric and Alex gave a presentation at their local WordPress user group, MSPWP, on using Docker to mount local copies of WordPress sites for development. They demonstrated editing a site from Visual Studio Code. Finally, they covered getting started with debugging using XDebug in VS Code. Only a week and a half before they gave their presentation they first began experimenting with Docker, and quickly recognized it as the future for their local development sandboxes of client (and personal) websites. It was recognizing its potential so immediately that led them to want to share their finding with others.

The remainder of this post is a reproduction of the tutorial document that they made available after the presentation to the user group (and this post is, for all intents and purposes, their own place to archive it for anyone to find in the future, and they hope for those who find it that it is useful to you).

Install Docker

To install Docker go to the Docker download page.

An Example docker-compose.yml

The first part of our presentation showed how to create a WordPress install using the standard WordPress image. Here is the contents of the docker-compose.yml we used:

version: '2'

services:
  db:
    image: mysql:5.7
    ports:
      - "3999:3306"
    volumes:
      - db_data:/var/lib/mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: wordpress
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress

  wordpress:
    depends_on:
      - db
    image: wordpress:latest
    ports:
      - "8999:80"
    volumes:
      - ./html:/var/www/html
    restart: always
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_PASSWORD: wordpress

    volumes:
      db_data:

We created a new folder, mspwp, put this docker-compose.yml in that folder, and created a folder named html in that folder. For the purposes of trying this out yourself, do the same.

Run your Docker WordPress Site

In a Terminal at the folder that contains your docker-compose.yml:

Start the Docker container:

docker-compose up -d

Hint: You can omit the -d if you want to see the log stream for the Docker in your Terminal output (but not be returned to a command prompt).

The first time you run the container it will take longer to start as it downloads and sets up the images specified in your YAML.

At this point you should be able to point your browser at localhost:8999 and see the WordPress set up screen. You can run through the setup as usual, and now you have a WordPress site running on your Mac.

To see all the containers Docker is running type the following in Terminal:

docker ps

A Note on the Files for this WordPress Install

After running the container once notice that the files for this WordPress installation are all in the html folder. You can edit any of them there and the changes will be reflected the next time you reload a page of the WordPress site.

To demonstrate this, add a new PHP file named info.php to your html folder that runs:

&lt;?php
echo "Hello MSPWP!";
phpinfo();

Save the file, then point your browser to localhost:8999/info.php. That file should load, and show you details on the PHP installation in your Docker.

Stopping your Docker

Take down the container by running the following in a Terminal at the folder you created above:

docker-compose down

Or simply quit the Docker app from the menubar; in this case when you relaunch Docker the containers (in this case, your WordPress site and its database) will automatically be ready to use. But to continue with this tutorial, for now leave it running.

Install Visual Studio Code

To install Visual Studio Code go to the Visual Studio Code download page.

Installing Extensions

Visual Studio Code has a number of extensions. To access these go to the Extensions area by clicking the square item at the bottom of items in the lefthand sidebar of the window. You can install whatever extensions you’d like, but for the purposes of this tutorial make sure to install PHP Debug.

Opening a folder in Visual Studio Code

Going back to the top item in the lefthand sidebar (Explorer) a Welcome screen should still be shown. In it select the Open folder… option, and select your mspwp folder.

Editing Local Files

Open up info.php from the files list in the folder you opened in Visual Studio Code. Edit the echo line to say something else. Save the file and reload your browser window (or if it is pointed elsewhere, point it to localhost:8999/info.php).

Try your hand at navigating in Visual Studio Code and editing some more by making a change to the header.php file of the active theme (probably twentyseventeen) and loading localhost:8999.

Set up XDebug

To set up XDebug in your container we need to modify docker-compose.yml. First take down your container.

Change the image line for wordpress to use the eceleste/docker-wordpress-xdebug image. Also add XDEBUG-CONFIG: remote_host={your ip} to the environment section under wordpress. This new image includes XDebug, whereas the standard WordPress image is just the vanilla WordPress install with minimum other software.

Note, to find your Mac’s IP Address run the following in Terminal:

ifconfig | grep "inet " | grep -Fv 127.0.0.1 | awk '{print $2}'

You can now restart your container.

Using XDebug to Debug PHP in Visual Studio Code

Go to the Debug area by choosing the debug item from the lefthand sidebar (thrd item down). Click on the green Run button, the first time you do this it should give you a menu to choose what kind of debugging to do, select PHP. This will create and open your launch.json file, which defines how the debugger should work. It is stored in the .vscode folder in your workspace (the folder you opened). The contents of this file should be:

{ 
  "version": "0.2.0", 
  "configurations": [ 
    { 
      "name": "Listen for XDebug",
      "type": "php", 
      "request": "launch", 
      "port": 9000, 
      "localSourceRoot": "${workspaceRoot}/html",
      "serverSourceRoot": "/var/www/html"
    },
    {
      "name": "Launch currently open script",
      "type": "php",
      "request": "launch", 
      "program": "${file}", 
      "cwd": "${fileDirname}",
      "port": 9000 
    }
  ]
}

To test debugging, add a breakpoint in your header.php (click in the gutter by the line number to set a breakpoint at that line). Then run the debugger using the green Run button in the Debug area. With the debugger running you’ll have a debug control bar towards the top of the Visual Studio Code window.

Just reload the page in your browser and the debugger should come forward when your breakpoint gets hit. Look at the variables in the Variables section of this view. You can find and inspect all the usual WordPress variables, including WP_Post.

You can also manipulate the page as it loads using the Debug Console (should be towards the bottom of the Visual Studio Code window). For example, you can modify the post title by typing the following into the console and hitting return: php $post->post_title = "Hello MSPWP"

The debugger can also be invoked for PHP notices, warnings, and exceptions. It will also let you follow all the way through your theme or plugin files, to parent theme and even core files, should you wish.

Copying a Live Site to your Container

To copy a live WordPress website to your container you need to both copy the wp-content files, and copy the database. We do not copy core files, as those might as well be the cleaner versions from the Docker image that was used.

Copy the wp-content files with the following while in your mspwp folder:

rsync -a example.com/wp-content html/

If WordPress is installed in a subdirectory, be sure to include that in the path to copy from.

Assuming that you’re using something other than wp_ as the table prefix, remember to update wp-config.php with the proper prefix for your site.

To copy the database, in an SSH connection to the live server, first dump the database contents (check in the live wp-config.php for the proper username and password):

mysqldump -u username -p password > backup.sql

Copy backup.sql to your Mac. Then you may want to drop the current contents of the database in your container, so in a Terminal on your Mac:

echo "drop database wordpress; create database wordpress;" | docker exec -i mspwp_db_1 mysql -u wordpress -pwordpress

Then import your backup file:

docker exec -i mspwp_db_1 mysql -u wordpress -pwordpress wordpress < backup.sql

Yes, this will generate a warning about the idiocy of including the password on the command line, but in this case we don’t really care. To make a fresh backup of the database in your container, just grab it from MySQL:

docker exec -i mspwp_db_1 mysqldump -u wordpress -pwordpress wordpress > backup.sql

About the Presenters

Eric and Alex Celeste do WordPress site management and development as Tenseg LLC. We have clients both locally and across the nation who work in a number of fields. We can be reached at [email protected]">[email protected].

New version of the Subcaucus Calculator

2015-12-19T12:00:00-06:00

The new version 2.0 of our subcaucus calculator SubCalc is now available on the App Store for iPhones.

This is pretty important because caucuses are coming up here in Minnesota and the old version no longer worked on most recent iPhones. SubCalc is back and better than ever. It now shares the exact same calculation engine that we use on the web version of SubCalc.

It is still free, so if there is any chance you may need some help doing the proportional representation math during the coming caucus and convention season, go get version 2.0 of SubCalc right away.

Admin Bar ID now on the Dashboard

2012-12-13T12:00:00-06:00

We’ve tweaked the WP Admin Bar ID Menu plugin to also add ID numbers when you are in the Dashboard. It can be frustrating to not know the ID number of an item you are working on, and digging those numbers out of the crowded URL gets old fast. Now Admin Bar ID Menu adds that ID number to the “view” item in the admin bar. It uses various techniques to figure out what the right number should be, we hope the bases are covered, but welcome your input if you find a case we missed.

You can get the update by simply checking for updates in WordPress if the plugin is already installed.

Subversion to Git Migration Checklist

2012-03-03T12:00:00-06:00

Just a heads up for everyone, this post is a highly technical one for fellow developers, it is not something we expect most of you to find helpful or even fully comprehend.

Earlier this week we took the dive and migrated all of our active projects (not all of these have been publicly announced much less released) from ProjectLocker Subversion to BitBucket Git. In the process we formulated a checklist of the steps needed in this migration process. We’ve decided to post that checklist as a guide for anyone else interested in migrating projects. Please note that this checklist is entirely independent of what services you use for Subversion and Git. Anything that is within “[]” is a variable that you have to replace with the appropriate value given your setup. We hope this checklist may save you some time searching for pieces of this process on various websites.

A. Setup

Make sure that all changes are committed into the SVN repo from Xcode

B. Migration

cd to svn checkout (project) directory
svn log -q | awk -F '|' '/^r/ {sub("^ ", "", $2); sub(" $", "", $2); print $2" = "$2" <"$2">"}' | sort -u > authors-transform.txt
Edit the authors-transform.txt file to match desired Git user details
cd to home directory root (or any other place for the temporary Git repo)
mkdir temp_git_repo
cd temp_git_repo
git svn init [URL-TO-SVN-REPO] --no-metadata
git config svn.authorsfile [PATH-TO-AUTHORS-TRANSFORM-FILE]
git svn fetch

C. Push to Git Remote

git remote add origin [GIT-REMOTE-LOCATION]
git push -u origin master

D. Replace SVN Version of project on filesystem/in Xcode with Git Version

This is self-explanatory and specific instructions for this can be found within Xcode and its documentation
Essentially what is important to remember is that you use the "Checkout or Clone Repository" option in the Repositories organizer and paste in the same [GIT-REMOTE-LOCATION] used above
You can also delete the temp_git_repo folder at this time along with the old SVN-backed project folder

WP Admin Bar ID Menu updated for WP 3.3

2011-12-16T12:00:00-06:00

We love WordPress updates and WP 3.3 is a doozy! Many things have changed, including the internals of how the admin bar is constructed. Today we introduce version 0.4 of our WP Admin Bar ID Menu plugin which allows the plugin to work with WP 3.3. Nothing else has changed about this plugin, it remains a very simple tool that just puts the ID number of a page or post into the admin bar alongside the “edit” menu item.