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 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: ,

GitHub Updater – the Path to 8

In July it will have been 5 years since the first commit to GitHub Updater. In its 5 year span it has grown significantly in its evolution from a single file plugin to the complex integrated object oriented plugin that exists today.

Version 8 will see a bump in the requirement to at least PHP 5.6. Yes, it does work in PHP 7.2 but as PHP 5.6 is the lowest version of PHP still supported, I thought this was a nice minimum requirement. When PHP 5.6 becomes EOL’d I will transition up to PHP 7. I can only hope that at some point WordPress follows suit. I have learned that what this also means is that the bootstrap file needs to be compliant with a lower PHP version or the file will white screen the user’s site.

Version 8 has also seen a more modular architecture to the core of the plugin. What this means is that I’ve added a number of hooks to now allow me to keep most of the specific code siloed into its own classes. This has especially been beneficial to the Settings and Install functions.

In the Settings, this can result in a slight cosmetic difference as the APIs are hit and the server specific subtabs display. I’ve added a number of icons, tooltips, and notices to let the user know what’s happening and that no it’s not broken.

In case I haven’t mentioned it before, GitHub Updater also works with WP-CLI and can be used with a webhook for a continuous integration type of updating.

There’s already been a bump to version 8.1.1. The new feature is automatic renaming of the GitHub Updater plugin upon activation. If the plugin is renamed the activation fails as the activated plugin no longer exists. It has been renamed. 😉

As always, the best source of current information about GitHub Updater is the wiki.

Here’s the changelog.

Filed under: code, WordPress

GitHub Updater and Background Updates

GitHub Updater is a WordPress plugin that seeks to emulate the wp-admin dashboard updating experience for plugins and themes hosted on other git hosts. Among the most popular git hosts to use for social coding, or simply provide an external version control system, are GitHub, Bitbucket, GitLab, and Gitea. In order to provide an identical in-app experience GitHub Updater needs to make 5-6 API calls to the get all the data required. There are ways, and hooks, to bypass some of these API calls and therefore speed up the process, but this can result in a lesser experience.

A solution presented itself in WP-Cron. By using WP-Cron I have been able to drastically reduce the time required to bring the site back to a usable condition while GitHub Updater does its API checks in the background.

Naturally there is a hook to bypass this system as troubleshooting when WP-Cron is active can be difficult.

Using a background process does mean that there may be times when the user might try to access an update or branch switching and it may not yet be available. I’ve tried to make as many indicators as I can to let the user know that nothing is broken and that they are simply waiting on WP-Cron to finish.

The overall result is a much faster response time and much less potential wait while the GitHub Updater cache is updating or being refreshed.

As always there is more information in the wiki.

Filed under: WordPress
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

Medical Staff – Hospital Alignment

I’ve been on staff and practicing at Desert Regional Medical Center for almost 20 years. During that time I have taken ED call for General Surgery and for half of that time for both Trauma and General Surgery. I have noticed many significant changes during that time.
Over the course of the past few decades the practice of hospital medicine has shifted significantly. Initially, ER call was the primary method of increasing your practice and with the payor mix there was never really an issue of either paid call or not having enough physicians taking call. Beginning around 15 years ago the reimbursement for physician services changed dramatically. It soon became obvious that office expenses were ever increasing and reimbursement was ever decreasing. The economics of the private practice physician was quickly becoming economically unfeasible.
Fundamentally the problem arises as many medical staffs, ours included, do not seem to understand the symbiotic relationship between themselves and the hospital. Many have openly expressed that the hospital wouldn’t exist without us. They don’t seem to understand that our livelihood also depends on a strong, viable hospital providing services and infrastructure that we depend upon. Most have no clear understanding of HCAPS scores, quality dashboards, PSI-90, or any other metrics by which hospitals are measured.

Giving Millenials a Bad Rap

As background, DRMC has never had large or even moderate sized physician groups. It has always been an aggregate of individual practitioners with a smattering of small groups. As the economics of medicine has shifted away from the viability of the solo practice towards a group practice, our physicians were set in their ways and seem unable to join together under any sort of meaningful cooperative venture. I believe that much of the current state, both in general and in specific, stems from the medical staff having a sense of entitlement. There are two distinct groups with different reasons for the sense of entitlement. Firstly, millennials, as a group, have a well documented sense of entitlement. This comprises our newer staff members. Secondly, our older, established physicians, seeing their reimbursement decline and their expenses increase believe they too are entitled because for years they supported the hospital and now they feel that the hospital owes them. With decreasing reimbursement there is more competition for patients.


Many specialists are holding the hospital hostage in exchange for ED call coverage. We have seen the rapid growth of hospital based physicians filling some of this demand. To these physicians the threat of no longer taking call is thrown at every opportunity to get something they need/want from the hospital.

Can’t Tell the Players Without a Scorecard

I believe the solution, or a solution, lies in the understanding that the economics of medicine has shifted from physicians with outpatient practices who often practiced at the hospital, to

  • outpatient practices who rarely practice at the hospital
  • outpatient practices who need the infrastructure and services of the hospital for their primary practice, and
  • hospitalist based physicians whose primary practice is the care of the emergency department patient and the inpatient.

The first group, those with outpatient practices who rarely practice at the hospital, aren’t the problem. Unfortunately they aren’t the solution either.
The last group, hospitalist based physicians, I believe, comprise the majority of the solution. However, the current economics of solely having a hospital based practice requires non-RVU based compensation in many circumstances. It really doesn’t seem to matter whether this practice is ER, Anesthesia, Radiology, Surgery, Trauma, Hospitalists, Intensivists, or OB Hospitalists. I think the opportunity to create buy-in with these groups is much greater as they clearly have more incentive to assist with hospital administrators and their goals.
The second group, solo or small group specialists, seem to have an unmistakable sense of self importance as they are the ones making all the money for the hospital. Because of this attitude they have little incentive or desire to assist in the overall goals of the hospital. They see the hospital as unable to exist without them.

I’ll Take Door Number…

I believe a hybrid solution is the answer. The administration should commit to a core group of employed physicians who would provide the bulk of the patient care for the ED and the inpatients. Whether these are directly employed physicians or physicians employed under a foundation model will depend entirely on State law and the hospital’s overall model. The traditional RVU based model will not work as the sole method of reimbursement as there are many intangibles, call coverage, physician alignment, etc. that are infinitely easier to accomplish and benefit the hospital more than simply counting RVUs. I refer to HCAHPS and other dashboard and quality metrics that may be difficult, if not impossible, to fully achieve without a motivated, responsive medical staff.
The challenge is with the second group. I believe here the solution may lie in creating service line co-management agreements with these specialists. It is important that membership in these agreements is controlled by the hospital and that there is a clear benefit to being a member and working towards the service line’s goals and objectives. Members could be given benefits, such as preferred scheduling of procedures as one example. Of course those not cooperating for the mutual benefit would loose out.
I understand that this is asking the hospital administration to offset declining physician reimbursement for the opportunity to have a much more engaged and aligned medical staff. I’m not quite sure an easier solution exists. But clearly having an engaged and aligned medical staff is essential to maximize both the quality and profitability of any hospital.
When I first became Chief of Staff, I told our CEO that if I had a problem, I would try to bring a solution as well. I never promised a perfect solution, but hopefully a starting point.
I believe there is a new paradigm in the delivery and practice of medicine and that new paradigm requires a tighter integration between hospitals and their medical staffs.
Any thoughts?

Filed under: medicine