Category: computer

GitHub Updater and Gitea

Gitea is the new kid on the block for creating a self-hosted git server. Gitea is written in Go and is highly performant with very low overhead. In fact, Gitea is so efficient you can run it on a Raspberry Pi. There’s another post coming about that. 😉

As with most integrations of new git servers into GitHub Updater it all starts with an issue and a user willing to help. In this case, the user was Marco Berchart.

Over the years, I’ve continued to refactor GitHub Updater to become more OOP based and adding Gitea support definitely shows that this was the way to go. Adding support for Gitea was far and away the simplest integration yet. Much of this has to do with API closely following the GitHub API.

Marco was kind enough to start by creating  a PR and we were able to work on a branch until it was complete and able to be merged. There is a demo site at https://try.gitea.io where a test account can be created. There is no guarantee any sort of persistence and don’t expect your data, or possibly even your user, to be around long term. Marco was able to provide an account on his Gitea instance for me to test. I couldn’t have finished the integration with this access.

Since then I have figured out how to install Gitea on a Raspberry Pi. I’ve actually done the process several times and even updated both Go and Gitea. It makes testing much easier for me and it makes setting up your own local git server for less than $100 simple.

Filed under: code, computer, WordPressTagged with: ,
Local by Flywheel logo

Local by Flywheel (Pressmatic) and Symlinks

I’ve changed development environments a couple of times. I started out using DesktopServer, a wonderful app. Gradually I grew disappointed with their update schedule and v4.0 ever on the horizon. One of the things I didn’t like was my inability to choose the PHP version I was developing in. I know there must be a way but it wasn’t obvious.

Feeling like I needed a challenge, I set out to learn how to use Vagrant and VVV cause all the cool kids were using it. Once I got it up and running it worked well. There were a number of quirky things that I needed to figure out for my workflow.

From my initial time with DesktopServer I was using GitHub and local git on my MacBook Air, using Tower, for version control. Currently I’m using GitKraken, but that’s another post. I kept all my local repos synced on GitHub. When using DesktopServer I would create a symlink to the /wp-content/plugins or /wp-content/themes folder of the local environment from my local repo.

This didn’t quite work in VVV as symlinks don’t work in Vagrant. Vagrant requires creating a synced folder which is similar, but not the same. I was able to create a Customfile, custom config file, for my VVV installation that would create synced folders at each vagrant up. This synced folder appeared on the desktop as an empty folder but in the site it ran perfectly. The problem was that in my IDE, PhpStorm, there was nothing in the folder to edit. I found that removing this synced folder and replacing it with an actual symlink made everything work in both my IDE and on the site. Perfect, I was back to my usual workflow.

The issue I had was that every time I did a vagrant up or a vagrant reprovision, Vagrant would destroy my synced folder and I would have to run the Customfile again to recreate it. As many know, Vagrant isn’t a speed demon during a vagrant up and the additional code of creating multiple synced folders was considerable. Add to that the extra step of creating the symlinks each time, then I was set.

When Pressmatic came on the scene I was already considering dipping my hand into Docker, but was slightly intimidated. Pressmatic made all of that so much simpler. Pressmatic was purchase by Flywheel, rebranded and released as a free tool, Local by Flywheel. OK so the name is kinda blah and the really cool Pressmatic logo is no more, but it works great! Local soon developed an add-on that created shared/synced volumes which pretty much was the same result as my Customfile in VVV. The only problem was I couldn’t find any simple way to re-create my experience of switching to a symlink. Part of the problem was that I was very dissatisfied with amount of time required at provisioning in Vagrant and the thought of having to do this multiple times a day was daunting.

I changed my workflow to use an small app that synced folders in the background. It worked, but was clearly a kludge. Out of curiousity I created a synced folder using the Local by Flywheel Volumes Addon and then changed this folder to a symlink. Instantly I was back in business when using my IDE. The best part was that the symlink persisted through the Local Machine restarts and re-provisioning the individual sites.

Since then I’ve created a bash script to automatically create the symlinks after the Volumes have been added. I can now effectly re-create my normal workflow and even better as in Docker, synced folders seem to be persistent.

I’m sure my understanding of synced folders was probably incorrect and they were persistent all along. I just didn’t see it at the time.

As of this writing both Local by Flywheel and the Volumes addon have been updated several times. The current versions are completely compatible and functional.

This setup may not be for everyone, but I’ve found it allows me to develop locally and continue to use git for version control.

Filed under: code, computer

Dreamhost, WordPress and WebDAV

So next on my list was figuring out how to create a nested group of password protected directories with different users accessing various sub-directories. It’s much simpler than it sounds. The only caveat was that the main domain is running WordPress.
As such I had to tweak the .htaccess file. Fortunately the instructions were simple.
Then I created a series of nested WebDAV directories in the Dreamhost Panel and assigned user accounts as needed. Every user needing WebDAV access got it for the primary WebDAV directory and then each sub-directory had only the user accounts as needed.
Surprisingly this worked great. I may need to get an SSL certificate for the domain if I want to have the WebDAV encrypted but that should be very doable.

Filed under: computer, web-hostingTagged with:

Transferring WordPress

So the benefit of having many domains to play with is that I get to test things out before I put them on a live site.
I was able to successfully transfer a multisite WordPress installation to @Dreamhost. Here’s what I did.

  1. Use 1-click installer to create base site @Dreamhost.
  2. Make site a multisite installation.
  3. Use SFTP to copy existing plugins/themes.
  4. Use WP Migrate DB Pro to push existing database to new database.
  5. Create mirrored subdomain in @Dreamhost panel for subdomains.
  6. Remember to check Remove WWW from the main domain.

Shout out to @Dreamhost support for pushing me in the right direction.
Next up, tackling IMAP email transfer.

Filed under: computer, web-hostingTagged with:

Not Running a Server

I’ve been running my own server for over 5 years now. It has been a great and sometimes frustrating experience. I think I’ve finally decided to let the pros do the server administration and just focus on the other stuff. The other stuff being coding, writing, and playing with technology.
I’m looking into @Dreamhost. They seem to offer a wealth of features at a reasonable price. Honestly what gives me the most anxiety is transferring all the old IMAP email over to the new host. There’s a wiki entry about transferring email and using imapsync. I really need to investigate this.
Wish me luck. Updates to follow.

Filed under: code, computer, osx-serverTagged with: