• Stay in touch. Sign up for the 9seeds newsletter.
  • The tools you use, the way you want. Wrapping Help Scout in Nativefier

    One of the things we love about WordPress is that it lets us affordably build custom functionality into business’ websites that not long ago would have required tens if not hundreds of thousands of dollars invested in custom software development costs. Which is to say we think people should be able to have software their way.

    Wrapping Slack “Making WordPress” in Nativefier

    wp-core-slack-900x900In that vein I was delighted when Jason Cosper wrote last week about using Nativefier to create a mini app for the Making WordPress Core Slack Team.

    Like so many businesses these days we use and have quickly come to rely heavily on Slack for our internal team communications. Increasingly however we’re also using it for external communications to keep in touch with specific groups, largely in the tech space but outside it as well.  I’ve heard of families starting their own Slack Team just to keep in touch.

    Personally I belong to 14 Slack Teams: 5 WordPress groups, 7 non-WordPress technology and local community groups, 2! groups dedicated to just to coffee and a few others. It’s crazy.

    One of those WordPress groups is “Making WordPress”, which is a massively huge group of over 10,000 members. It’s a vital communication channel though for everyone involved in the broader WordPress Community. Everything from Core development to organizing WordCamp events to updates to the WordPress.org website to securirty alerts gets discussed there.

    Less to it’s core mission it’s both a great way to keep in touch with friends made at WordCamps as well as a great back channel between agencies working in the WordPress space.

    Jason Cosper discovered the cause of something that had been driving me crazy the last few months with the native Slack app though.  It had become extremely unstable It was frequently crashing and taking up 100% cpu. That’s really frustrating when it’s something you rely on nearly every minute of your work day.

    It turns out a big cause of that was including “Making WordPress” and it’s 10,000+ members in the native app. Jason removed that channel and wrapped it up in it’s own desktop web app using a new tool called Nativefier. It’s much like Fluid and what we called an SSB (Site Specific Browser) apps if you ever used those back in the day.  Since removing Making WordPress from my native Slack app, like Jason, I’ve found it to be much snappier and hasn’t crashed once.

    The now isolated Nativefier app version of Making WordPress still gives me critical desktop notifications of direct messages, plus has the added benefit of staying out of my way most of the day. As you might imagine with 10,000+ members it can be a bit noisey.  It’s a win win.

    Wrapping Helpscout Making WordPress in Nativefier

    Nativefier-Help-ScoutIt occurred to me I could do the same thing with a few websites I like to keep open all the time. Starting with Help Scout which we use for tracking and responding to plugin support requests.

    Steps for Mac OS X

    Step 1:
    Install Nativefier.

    Ok, it’s a bit more complicated. You need to have Node NPM installed first, but if you’re a developer of any kind you probably already do have that. Then just at the command line:
    npm install nativefier -g

    Step 2:

    Wrap up a web page in Nativefier, I did this in ~/Applications and then moved it to /Applications.

    nativefier --name "Help Scout" "https://secure.helpscout.net"

    Step 3 (optional):

    It’ll grab the favicon by default, but his is often low res and ugly.  Replace it with a nicer icon.

    I used https://iconverticons.com/online/ to convert a Help Scout PNG I scrped from their site into the ICNS format I needed for the dekstop app.  You can grab them here for Help Scout if you want: https://iconverticons.com/icons/93a786b5f69feea3/ or create your own.

    Final Step:

    Right click on the new app and select Open. You’re going to need to right click open on it the first time because it’s not an officially signed by Apple app, but you created it so you can probably decide trust it when the pop-up warning about it being untrusted comes up.

    Now if the < 5 minutes it takes to go through those steps yourself is too much, or you don’t have NPM installed, or if your command line shy.  You can download my Nativefier wrapped up app of the Help Scout website here: Nativefier – Help Scout.


    I can imagine others using this for Gmail, Calendars, all sort of things…  Let us know what you’ve used it for in the comments!

    Creating a WordPress User when you don’t have an existing admin login to use

    A long time ago we wrote a post on how to insert yourself into WordPress as an admin that has been very popular.

    Just to be clear, this won’t help you hack a WordPress site. You have to have some kind of server level access to make use of any of these, but in our work we often have scenarios where we only have access to a server.

    There are 3 quick ways to create a WordPress user from outside the WordPress dashboard.

    Creating a WordPress user with WP CLI USER CREATE

    My new favorite way is using WP CLI.  These require that WP CLI is installed on the server, but recently WP Engine started rolling out WP-CLI Support to Select Partners for Beta Testing.  It’s not just a WP Engine thing though, a few other hosts provide WP CLI support via shell access and if you’re running on your own server you can install it.  You’re not likely to be able to install this yourself on shared hosting.
    Assuming you got access to WP CLI it’s as easy as SSH’ing into your server, or using the WP Engine portal, and typing

    wp create user name [email protected] --role=administrator

    You can specific a password with –user_pass=”Password!” or let it create a random password for you!



    Create a WordPress user via MySQL

    If you don’t have SSH access and WP CLI already installed the next quickest way is to insert a user via MySQL. Most hosts include PHPMyAdmin so you can just jump into there, select the database you want to insert a user in, paste this code into the SQL page, edit the values and click Go.

    SET @user_login := 'justin_foell';
    SET @user_pass := 'Q9xiHgzZ';
    SET @user_email := [email protected]';
    INSERT INTO `wp_users` 
    (`user_login`, `user_pass`, `user_email`, `user_registered`) 
    (@user_login, MD5(@user_pass), @user_email, now());
    SELECT @user_id := LAST_INSERT_ID();
    INSERT INTO `wp_usermeta` 
    (`user_id`, `meta_key`, `meta_value`) 
    (@user_id, 'wp_capabilities', 'a:1:{s:13:"administrator";b:1;}');
    INSERT INTO `wp_usermeta` 
    (`user_id`, `meta_key`, `meta_value`) 
    (@user_id, 'wp_user_level', '10');



    Create a WordPress user via FTP

    This used to be my favorite way because often all I had was FTP access, but these days I use the first two a lot more often.  Still it’s easy, especially if running running MySQL commands scares you.

    Here you simple FTP to root directory of the site you need access to and create a new empty PHP file.  Often I just “duplicate” an existing file and clear it out, that’s fine too.

    Open up the file and insert this code, then change the user/pass/email values and finally visit the file in web browser.  You should delete the file after it runs, or at least give it very unique name.

     * Create Admin User
    $jb_password = 'PASSWORD'; #enter your desired password here, if you don't line 16 makes sure nothing bad happens like setting you actual password to 'PASSWORD'
    $jb_username = '9seedsJB';
    $jb_email = [email protected]';
    if ( $jb_password === 'PASSWORD' )
    if ( !username_exists($jb_username) && !email_exists($jb_email) ) {
    	$user_id = wp_create_user( $jb_username, $jb_password, $jb_email);
    	if ( is_int($user_id) ) {
    	  $wp_user_object = new WP_User($user_id);
    	  echo 'Success!';
    	} else {
    	  echo 'Error with wp_insert_user. No users were created.';
    } else {
    	echo 'This user or email already exists. Nothing was done.';

    Thats it!  3 ways to create a WordPress user when you don’t have dashboard access.

    Extending The Functionality of MemberPress




    There are a number of well established commercial WordPress plugins that provide an almost perfect solution out of the box for our customers. These plugins are big part of what makes WordPress a great and affordable solution for so many websites. Often however, a business needs something “just a little custom”. Where a full custom solution might be tens of thousands of dollars in development, a $100 plugin and a few hours of custom development can deliver a similar highly tailored solution. This recently completed project extending MemberPress is a great example.

    Unique Client Needs

    A client using MemberPress came to us wanting to offer their members the ability to purchase a gift membership for someone else as well as a way to set up and manage a very customized 40 day email drip program.

    Taking Something Good And Making It Better

    We love working with the MemberPress plugin. It’s robust and can meet the needs of many membership sites. However, each business is unique in the services it delivers to it’s customers and sometimes delivering those services requires extending the functionality provided by a plugin.

    Implementing the gift memberships was more challenging than it sounds. The existing coupon functionality in MemberPress assumes that a site administrator would simply create a coupon code for use by many users. We started with this and extended it such that users could purchase a 100% coupon and that coupon could be sent to someone as a gift. The final tweak was to make it so these coupon codes were one-time use only.

    The 40 day drip program took people through a series of daily questions about each day’s lesson. MemberPress tracks progress through the drip program but doesn’t allow users to go back and repeat the program. We created a plugin that allowed users to reset the program to day 1 and wiped out all of their previous answers so they could start the process anew.

    Both add-ons work independently of one another giving the site owner flexibility in which add-on functionality is active at any given time.

    Customized Solutions

    There are countless amazing plugins out there that do a massive range of things for a specific need. When you need something a little different the most affordable solution may be to extend one of those existing plugins to fit your particular need. Contact us. We’ll create the perfect plugin add-on for you!

    Updating WP Chargify: Revisiting a Custom Plugin Built Long Ago


    5 years ago, Jason Glaspey came to us wanting to use Chargify to manage recurring subscriptions for his paid members. At the time there was no plugin available for WordPress to connect with Chargify. Jason hired us to build a custom plugin for his specific needs. He also generously allowed us to make it available for free to all on the WordPress Plugin Directory.

    Over the years Chargify has made lot of changes to their service. While Jason had sponsored the original plugin he moved on and the plugin sat idle for quite a while. Chargify recognized the importance of the plugin being updated and reached out to us to do a complete overhaul.

    We were excited to take on the project. It was great to be given the opportunity to revisit code we wrote so long ago. We were able to update the plugin with all the latest Chargify features as well at the latest best coding practices.

    Chargify was delighted with the results and wrote a nifty post on it where you can read about all the new functionality here.

    Thanks to 9seeds great work on our plugin, using WordPress and Chargify together has never been easier!” ~Britton Gwaltney, Chargify – Director of Sales

    Building custom plugins for hire like this is one our favorite services. If you need a custom plugin developed or just need to streamline a function please contact us! We’ll be happy to help you, too.


    Deploying to SiteGround via git push

    Git push is the best thing for deployments since sliced bread. I don’t know if sliced bread was ever a deployment requirement, but trust me it’s good. I used to work at a company that used a similar stack (svn+rsync) to deploy. I’m glad to see many hosting companies getting on board with git-push. May you never have to use FTP again!

    We have an account at SiteGround, which provides git push, but implemented in a different way than others like WPEngine. If you’re not careful with how you use it, it can lead to some strange results. I’d like to highlight some of the differences, so you don’t get yourself into trouble – especially if you don’t want core WP files to be under version control.

    Navigating SiteGround’s cPanel

    SiteGround uses the classic cPanel interface. To help you navigate, I’ve highlighted the areas of interest:

    cPanel home

    Creating a subdomain

    If you haven’t done so yet, you may want to create a subdomain for your install. We use a single domain at SiteGround and put several WP installs using subdomains for testing purposes. Here’s what the subdomain configuration looks like:

    cPanel subdomain

    If you’re setting up a WP install using your main domain name, you can skip creating a subdomain.

    Creating your WordPress instance at SiteGround

    When you go to add WordPress to your domain through cPanel, you’ll be using a tool called “Softaculous.” Click the big blue Install button to get started:

    cPanel new install

    Select the domain (or subdomain) that you want to turn into a WP install.

    Remember to change:

    • Database name – it will be auto-generated, I tend to choose something that matches the domain or subdomain so it’s easy to remember what it goes with.
    • Table Prefix – I use the normal wp_ – I think changing this has become “security through obscurity” and if you don’t keep your site up to date, this is unlikely to save you from an attack.
    • Admin Username – replace the auto-generated username with something useful, but avoid admin since it is easily targeted by attackers
    • Admin Email – replace the auto-generated one with a real email address for the site administrator.

    When the installation is done, to exit Softaculous and get back to the regular cPanel, just click the My Accounts tab at the top and then click the red Go to cPanel button.

    Creating the git repository at SiteGround

    Click the SG-Git icon on from cPanel. You’ll be brought to a screen where all of your WordPress installations are displayed, and if they don’t have git repositories associated with them, you’ll be given the option to create one. When you click Create Git Repository for your WP install, a dialog will come up with some git information. Record the git clone command, we’ll use it later.

    cPanel git info

    There will also be a SSH key and possibly the passphrase that goes along with it. Rather than using this key and sharing it with all the developers who you want to be able to push to this SiteGround account, I find it easier to add individual keys via cPanel.

    Setting up SSH keys and config

    SiteGround only takes DSA keys for SSH. If you don’t have an id_dsa.pub file in your ~/.ssh directory, you can create one by opening a terminal and running:

    ssh-keygen -t dsa

    Once your DSA key is generated, you can add it to the SiteGround control panel by clicking the SSH/Shell Access icon in cPanel. Copy the contents of your ~/.ssh/id_dsa.pub file and paste it into the text area on SiteGround:

    cPanel ssh key

    Some git clients won’t accept the fact that SiteGround uses a non-standard port for SSH. The way to get around this is to create a ~/.ssh/config file with an entry for SiteGround. If the git clone command SiteGround supplied looks like:

    git clone ssh:[email protected]:18765/home/sguser/public_html/git

    Then your ~/.ssh/config file should contain:

    Host mXX.siteground.biz
            HostName mXX.siteground.biz
            Port 18765
            User sguser

    Replace the Host, HostName, and User values with those from your account. I’ve changed them in this example for security purposes. To test you should be able to:

    ssh mXX.siteground.biz

    Notice you shouldn’t have to supply the username or the port, my ~/.ssh/config takes care of that. If you didn’t add a passphrase to your DSA key, you should be logged into SiteGround without having to supply a passphrase. Press Control-D to log out.

    Now your git endpoint can be simplified for your git client (username and port are removed):


    But don’t clone it just yet!

    How not to push, and what will happen

    The normal Git push workflow (for me) would be to init a git repository on my local system, add an origin of bitbucket.org or github.com and push it there, then add remotes (such as WPEngine production and staging) and proceed to push to those remotes. Instead I added SiteGround as a remote named sg-remote.

    Origin vs. Endpoint

    They key difference between SiteGround and WPEngine is that SiteGround treats their git repository as an origin (where you can pull and push), where WPEngine is a --bare endpoint that you can only push to.

    Since SiteGround is set up as an origin, if you just try to push there (without pulling or cloning from SiteGround first), you’ll likely get a warning like:

    Updates were rejected because the remote contains work that you do not have locally.

    Per git’s recommendation, you might then try to pull:

    git pull sg-staging master

    If your git repository was set up to not track WP core files, you’ll get a warning that:

    error: The following untracked working tree files would be overwritten by merge:

    This is because the core WP files have been added to the SG-git repo, but not your local one. So then if your next move is:

    git push sg-staging master --force

    Several important files will be removed on your WP install at SiteGround: all of wp-admin, wp-config.php, and all other PHP files in the webroot folder. Needless to say, your WordPress instance will no longer function without some serious repair.

    Git push to SiteGround (modified functional workflow)

    Since SiteGround sets up the git repository as an origin, it is better to start your WP project with a git clone from SiteGround, but before doing that, I wanted to clean things up…

    If you don’t want core WP files under version control, the easiest solution is to remove them from version control directly at SiteGround before cloning the repo.

    Since we’ve already got SSH working, from your terminal you can:

    ssh mXX.siteground.biz
    cd /home/sguser/public_html/git
    git rm --cached -r wp-admin/ wp-includes/ *.php *.txt *.html
    git commit -a -m "Removed WP-Core files"

    Again, replace the host (ssh line) and path (cd line) with the values from your git clone command supplied by SiteGround. The ones used here are examples. The git rm --cached command removes the core WP files from revision control, but leaves them on the filesystem, so your installation doesn’t go into a state of disrepair (like above).

    Once that is done, you can clone!

    git clone ssh://mXX.siteground.biz/home/sguser/public_html/git

    SiteGround will be the origin, so let’s edit that (usually bitbucket.org or github.com is the true origin). This will rename it to sg-remote:

    git remote rename origin sg-remote

    Now when you want to push to SiteGround, just do:

    git push sg-remote master

    If you try to push a different branch to SiteGround, the branch will be transferred, but the code won’t be switched to that branch. To get around this you can overwrite SiteGround master by doing:

    git push sg-remote my-branch:master

    Hopefully this gives you some insight into how the SiteGround git deployments work, so you can use them effectively.

    If you’re interesting in learning more about git deployments or how to set up your own git-push-to-deploy, I recommend starting with this article to familiarize yourself with a basic setup: