There are some cool new features, like a global installation so that you can run homestead commands from anywhere. Genius! It’s always a bit of a hassle to have a terminal open to your VM folder if it’s not a part of the current project, and obviously you can use Homestead on multiple projects. The configuration file is also now outside the main repository, so you will be able to upgrade your Homestead installation without git stashing your Homestead.yaml file.

However, when I did the global Composer install, (and adding `~/.composer/vendor/bin` to my PATH), I noticed that `homestead up` was trying to create a new box, but was erroring out because there was already a box titled “homestead”. I also didn’t feel like removing the old box, since it had all my databases set up in all my projects. So what to do?

Fortunately, in a hidden .vagrant folder, there are two key files, `id` and `index_uuid`. If you did a `homestead up` and it failed, you will find these files in `~/.composer/vendor/laravel/homestead/.vagrant/machines/default/virtualbox`. Copy the two files over from your original Homestead’s installation, which would be something like `Homestead/.vagrant/machines/default/virtualbox`.

Doing that, you should be able to use the global `homestead` commands and continue on your merry way!

However, at the times when I forget to add these files at the beginning of a project, it’s easy for them to be included accidentally. I just did this the other day, created a new Bedrock project, opened it in PHPStorm to make a few edits. Ran git init from the command line, committed all files, and pushed up to Bitbucket. Then I saw that .idea folder in there. Drat.

So I got a crazy idea. Is there a way to globally ignore files in Git? I can’t think of any reason where you would want to commit a .DS_Store file. Turns out there is.

It’s super simple. Create a new .gitignore somewhere, probably ~/.gitignore, or in my case I have a system config Github project so I can keep some settings across multiple computers. I added the .gitignore there. So far I’ve only added .DS_Store and .idea

Then type this command:

git config –global core.excludesfile ~/.gitignore

Easy peasy, and oh so good.

I’d like to think I’m going to get back into blogging. There are always things to talk about, things I learn I want to share. So I think I’ll try to set aside some time every day to do that. Other people seem to be able to get a quality blog post up every other day at least. So I ask, why not me?

We all know that.

WordPress is set up with an extraordinary amount of hooks and filters so we don’t need to touch core files. But what about those times when you find something that you CANNOT do without hacking core? What should you do?

The vast majority of the time, you should figure out a new game plan. So far, I haven’t found anything where I need to permanently hack core files to accomplish something. But I was just in a situation where I found it extremely helpful for a site migration.

The Story

I was converting a large magazine / article type site from a custom CMS to WordPress. Article content was imported just fine via a .csv file and the CSV Importer plugin. User import was also relatively straight forward in a similar fashion, using Import Users from CSV. One thing I can’t stress enough is reading the FAQ’s, documentation, studying the examples, etc., of these plugins in order to understand how they work and how to get the most benefit out of them.

The issue came from trying to correctly connect posts to users/authors. The old author ID of each post could be imported with the post content, but that didn’t line up with the new user ID’s that were assigned to the imported users. I considered doing a comparison of the old user ID’s with the new ones, and then assigning it a new author ID. That sounded like a headache though, and I felt like doing this:

So I got to thinking. How can I import the old user’s with the same ID? That sounded like a good idea. That would make the post import super easy!

The Plan

So how would I be able to get the users imported correctly? Diving in to the Import Users from CSV plugin, I found out a few things about how WordPress handles creating and modifying users. It was an interesting learning experience. The key was that I found out that wp_create_user uses wp_insert_user. And that wp_insert_user can be used to replace users. Why is that important?

Users in the previous CMS had been deleted, so the ID’s were in order, but there were holes. For example, it would go from user ID 12 to user ID 20. Inserting users like this would create user ID 12, and then user ID 20 would become 13. And that’s not what I wanted. But with how wp_insert_user works, I could replace users according to ID. So with a little help from wp-cli, by using:

wp user generate –count=650

I was able to generate enough users to all be replaced. After the import, a quick search showed all users who had not been replaced, those “holes” in ID’s, and I deleted them. A pretty clean import.

All except for that username. I didn’t want the users to all be user_<number>, as that is how wp-cli generates fake users. That wasn’t how they were set up before, obviously. Now what to do?

The Hack

WordPress (for good reason) does not allow you to update a user login after it has been created. Not from the dashboard, and not from wp_insert_user either. What to do? Hack WordPress, of course!

wp_insert_user first of all checks whether you are creating or updating a user. If it’s a new user, the user info is inserted into the database, and the user_login is added, or else the ID is used and the user_login is ignored. You can see this in the wp-includes/user.php file, from line 1820-1826, as of WordPress 4.0

Notice right above those lines though, on line 1817? An array is being created with user variables. Practically everything but user_login. So what if I added the ‘user_login’ string? BAM! Mission complete.

I hacked core, but it was a simple update, and was only happening in my development environment, I didn’t load this installation of WordPress onto the production server. But the database was complete.

Moral of the Story

There’s a few things I took from this project, and some thoughts that were reinforced.

1. Hack core. Just not permanently. If you have a specific goal to accomplish though, it’s a no brainer. I’m glad that I learned at the very beginning of my development career some good practices like not modifying vendor files, but that doesn’t mean you shouldn’t know what’s going on, and what your options are. Knowing how things work means knowing how you can fix issues, what you can work with, what you can break, all those good things. That brings me to point number 2.
2. Read source code. Know the application you’re using. It’s not as scary as you might think, if you don’t do it already. I know I didn’t for a long time, I just Googled and hoped for the best. That works, but reading what is ACTUALLY going on is the most helpful.

It’s true, my WordPress core hacking wasn’t a big deal. But it helped me accomplish a job. Read source code, know what’s going on, understand what’s happening behind the scenes, and you’ll be much better off for it.

Chrome and Firefox, of course, displayed beautifully. I was using a bit of a trick to get an inset shadow on the top and bottom, but not the sides of a container, with CSS that looks something like this:

.container { box-shadow: inset 0 -10px 20px -18px black, inset 0 10px 20px -18px black;

With this, you can create a pretty nice effect. The issue was that IE9 and IE10 looked as if they were not applying the box shadow at all. Strange, I think, so I make sure IE is in standard mode, yep. I started turning other CSS parameters off, nothing helped. I found this blog post about how

border-collapse:collapse;

will cause IE to not display a box-shadow. That wasn’t my issue though….

So I tried making sure box-shadow was working at all in IE10. If I removed my code, did a simple 10px 10px 10px black, yep that worked. Alright, so there’s something wrong with my CSS rule… It’s valid, and it works in Chrome….

Playing with the pixels showed me the issue. The rendering of the 4th pixel declaration refers to the shadow’s spread radius. Making this a negative along with moving the shadow up or down via the 2nd pixel declaration, you can have a box shadow that only appears on the top, or only the left, etc.

Internet Explorer does not render quite the same as Firefox and Chrome, however. What was happening was that the shadow was essentially hidden, not being rendered in the viewable space. Increasing the spread or moving the shadow caused it to be too dark and large in Chrome and Firefox. I settled on reworking it quite a bit:

box-shadow: inset 0 5px 12px -5px #ccc, inset 0 -5px 12px -5px #ccc;

This gives a similar effect but renders correctly in all browsers. Using a shade of gray that is much closer to the intended shadow color helps to reduce the need for spread of the shadow.

Cross-browser testing, I tells ya.

Before I get into the benefits, if you are unsure of what a VPS, or virtual Private server is, let’s mention that. A VPS is a virtualized operating system, in this case, an entire Linux operating system that you would manage. This means that you would get an actual server, with a set amount of CPU cores, RAM, and hard drive space. This is not the same as a dedicated server, as you are still sharing a larger server with other virtualized operating systems, but in most respects, this is a full server that you can do practically anything with. And unless you sign up for a managed VPS, you generally get a fresh install of your choice of Linux distribution, and you would need to configure nearly everything from the ground up. That means setting up PHP, MySQL, and Apache or Nginx, or anything else you might want to run.

So why would you ever want to learn server administration when shared hosting basically takes care of that for you. It’s true, it is easy to install WordPress, Joomla, Drupal, and plenty of other popular CMS’s on shared hosting. It also takes much less configuration. I myself have set up plenty of WordPress sites on many different shared hosting accounts for various clients. But I have moved to a VPS, and recently got a client to move away from shared hosting and host with me. So what are the benefits? Well let me tell you:

1. Freedom – Have you ever wanted to use an updated version of PHP, but your host only has a version that is 4 years old? What about one of those fancy server caching programs? With shared hosting, you’re stuck with whatever they give you. With your own VPS, you can try out, test, and use practically any program and any version you wish. What about Nginx? I don’t know of very many shared hosts that offer Nginx over Apache.
2. Security – it’s true that many of the better shared hosts are pretty secure. It’s also true that setting up your own VPS with security in mind will take more time, not just in the setup, but in research and time reading. After you have the know-how, the ability to SSH to your server, along with using SSH keys, port blocking, user management, and the list can go on, these can go a long way in adding to the security of your server.
3. Performance – This needs to be examined before proclaiming it as absolute over shared hosting, but generally it would be true. With a VPS, you get a chunk of an actual server, and your virtualized OS is yours. CPU time is something that can be over shared, but generally, you know what you are getting, and generally, it will be faster and more flexible than what shared hosts offer. With shared hosting, you do not know how much RAM you have available, how much drive space is left, and generally you are at the mercy of everyone else sharing the server, with the hopes that their sites do not get much traffic or hog a lot of CPU time. On a VPS, you know what you have, you can monitor your resources, and you can find ways to make your server quicker.

I could go on, but those are some of the key areas I enjoy from using a VPS. To be fair, I actually enjoy learning how Linux works and setting up servers, learning to do new things with it. I’m sort of strange like that.

Now let me give you an idea of the flexibility and speed that I have with a VPS that only costs me $40 a year. I recently set up a client’s site on my dev server, which runs Nginx behind Varnish cache (Varnish is not always on, but to test speed I have it set up). With Varnish correctly set up with WordPress, my client’s site was loading in around 800ms. We loaded his site on his shared hosting account, which was Yahoo (Biggest. Headache. Ever.) Yahoo was loading his site consistently at around 3-3.5 seconds. Yes, we are talking seconds, but I’m sure you will agree that page load times mean a lot on the web, and in instances where we are talking 3 to 4 times difference in speed, I call that a huge advantage.

I highly suggest trying out setting up your own server. It can be difficult to get started, but it’s rewarding, and will help you to continue growing in your developer skills. I won’t tell you it’s a walk in the park, it takes some patience, research, some trial and error, and most importantly, time. But you will be rewarded with faster, more secure sites, and more knowledge of how your website runs and should run.

I haven’t tried too many VPS hosts. I am currently with Weloveservers (that is an affiliate link), and so far I am impressed. Their prices are very competitive, and performance so far is excellent. They only offer support via tickets in the control panel, but they respond very quickly, so I don’t mind the lack of phone support, (I don’t like waiting on hold anyways).

Other hosts I have seen high praise for are Linode, Server Grove, and Digital Ocean. I have tried Digital Ocean, and their VPS’s are snappy, no complaints there. 

I will be getting a few tutorials up in the future about my experiences setting up my own servers, so stay tuned

The email I received talked about being ‘courageous’. Mr. Irving was referring to his clients, and the courage it takes to build your own business and your own website. I think he was also referring to the courage it takes to host a website on their servers.

He continues on after that to talk about the improvements they’ve made to their website, streamlining everything, improvements to hosting, etc. Visiting their site today, I see they’ve made it more attractive, and they have Jean Claude Van Damme doing the splits as their first slide on the homepage slider. I can’t deny how awesome that is.

Unfortunately, claims about improved hosting and world-class customer service I cannot agree with. I decided to reply to Mr. Irving in his email he sent, and I explained to him why I do not recommend Godaddy, and went into a relatively long dialogue about my experience with their hosting service. Was it too long? I don’t think so, I doubt it took more than 5 minutes to read.

Without copying and pasting my experience I sent to him, I will abbreviate. Basically, I have had two clients with Godaddy hosting I developed WordPress sites with in the last 9 months. I use the Roots theme as a base, and it makes clever use of redirects to redirect calls to the theme, changing /wp-content/theme/my-theme/assets/ to simply /assets/. This includes the Javascript, Image, and CSS folders. It’s a simple Apache .htaccess redirect, one line really. It’s simple and standard stuff.

Anyways, the two clients I had that had new WordPress sites uploaded by myself, were working…. for a week. I swear, one week, both times. Then the redirects stop working, just like that. No rhyme or reason, other than they worked at first, and a week later, boom, 404’s on CSS, JS, and image files being loaded from the theme.

The first time it happened, I thought it was my fault, and I freaked out. The second time, I made the connection that it was the 2nd site hosted on Godaddy, and realized it was a redirect issue. So I made the mistake of calling customer support for help.

I can’t begin to tell you the mistake that was. The person I first talked to said there was an issue with the files not loading. Yes, I agreed, it was a redirect issue. He said nothing had been changed on the server, so it must be something I did. Ok, not a completely illogical conclusion, but I was pretty convinced it was the a redirect that was not loading correctly from the .htaccess file. I asked if he had much experience with .htaccess, he said no, so he got a higher-up tech to help.

This higher-up apparently had experience with WordPress, so she was going to help solve the issue. What she decided to do (I’m not being indiscriminate, it was stated by the support person it was a woman), she decided to start moving my WordPress installation around in an effort for the files to load correctly, along with modifying the database to get things working. I guess it was a mistake to have WordPress installed in it’s own folder.

Once she had moved it out of the wp directory, and it still didn’t work, she told the Godaddy support person that I have hardcoded links to my files in the theme (not even remotely true), and I should fix that. I watched via FTP as she moved around files. I thanked the support person kindly, and I’m not being sarcastic, for having his tech move my files around without my permission, break my site further, and hand it back to me. He apologized, and that was that.

I reinstalled WordPress and the site’s theme and database, unsure of exactly all of the “fixes” the tech had made. I then proceeded to removed the function that set up the redirects from the theme, and voila, the site loaded perfectly. It has been running fine since then. Just with the longer and un-hidden calls to /wp-content/themes/blah blah blah. No big deal really, but it also shouldn’t be an issue. And that is MY issue.

Ok, so that turned into another rant. In any case, Godaddy has server issues that they cannot or will not acknowledge. No other hosting company has had this issue. I don’t even get into how slow their shared or grid servers tend to run. Thus, I told Mr. Irving I don’t recommend Godaddy for hosting. I don’t exactly blame him for not responding to my email, after all, I don’t have hosting with them, and I only have two past clients that have hosting with them, I am a very small fry.

Still, the hundreds or even thousands of experiences of others online who can’t stand Godaddy are evidence. But I suppose, since their servers are overloaded with hundreds of websites per, that they aren’t exactly hurting for sales either. So, touchè Godaddy, you have sales, you don’t need me or my fancy Apache redirects.

PS. Searching for the Godaddy logo on Google, I understand why they get sales. Pretty girls do sell

I’m starting a new project this week. I’ve used Roots on quite a few projects now, and enjoy working with it immensely. I also enjoy Twitter Bootstrap, but in working with it, I’ve found that it is rather heavy, and when I am handed a completely custom site to develop, I tend to do more overwriting of Bootstrap styling than necessary. So this next project, being that it is also completely custom in design, I wanted to use something much lighter than Bootstrap but still full featured.

Before I continue, I would like to point out that Ben Word and his friends are making impressive strides with Roots. Bootstrap is actually very customizable now, you can work with the LESS files and include or exclude large parts of the Bootstrap framework, and along with using Grunt.js, your css and javascript will be minified and concatenated as well. Pretty handy, and makes for a lean and mean website.

If you’re not yet familiar with how Roots works, or if you’re not using Grunt.js to handle this stuff, then you should probably visit the newly opened roots.io site and read up on how to utilize Grunt.js, it’ll change your life, for reals.

Now, in my particular case, I want to try using a lighter CSS framework, (I love trying out new things), so I’ll be utilizing Pure CSS by some of the good folks over at Yahoo. As you can see, the entire framework is only 4.3kb after being minified and gzipped, not too shabby. I also enjoy working with SASS and Compass more than LESS, so I’ll be clearing out Bootstrap and any LESS files and setting up my own SASS files.

Ok, with all of that background set up, let’s get to the actual tutorial section.

Setting up the theme

First thing I did was set up a new local WP installation. I used Yeoman and Wesley Todd’s WordPress Generator to do this, but you can do it the old fashioned way as well. What you will want to do next is get the most current Roots theme installed. Either download it from their website or use Git. If you have Git installed, then you can grab it like so:

git clone git://github.com/retlehs/roots.git

You can either do this in the wp-content/themes folder, or you can create a symbolic link to it if you are like me and want to keep your themes in their respective working folders (I have all of my work on a separate hard drive in my desktop PC). Now Git is set up and the theme installed, I’m going to start customizing it a bit.

First thing I did was copy the contents of the app.less file to an app.scss file. So in the theme folder, in assets/less I opened the app.less file, copied the contents of that, and created a new folder in assets called “sass”, and created a new file app.scss and pasted in the contents. I also commented out “@import “bootstrap/bootstrap.less”;” at the top, since I won’t be using Bootstrap.

Setting up Pure CSS

Second, I want to download Pure CSS. There are a lot of options to download it, including Git and Bower. Since this was my first time installing it, I wanted to see how the creators set it up. So, following their Github page instructions, I cloned the repo in my css folder and set it up with npm and grunt. I used the default commands:

$ git clone git@github.com:yui/pure.git
$ cd pure
$ npm install
$ grunt

Now I have a “pure” folder in my css folder, and the pure folder has a build that contains all the css. So it’s ready to go, but I’ll probably want this included with my main Grunt configuration.  So I open up the Grunt.js file included with Pure, and…. it’s over 400 lines long. Hmm…. ok, perhaps we can skip including ALL of this. For the moment, I’ll include the generated CSS files and call it a day.

Removing Bootstrap

I went into the main Gruntfile.js that is included with the Roots theme, and I commented out the sections that contained Bootstrap specific content. I commented out all .js files under “uglify” in the bootstrap folder, as well as the entire “less” section under “watch”.

Adding SASS/Compass

Finally, back near the top of the file, I changed the “recess” section, in “files”, I changed the line ‘assets/less/app.less’ to ‘assets/sass/app.scss’. This is obviously completely optional, depending on the pre-processor you’d like to use.

After doing this, you can run grunt to make sure everything is working. Remember to type “npm install” in the root of the theme if you haven’t done so yet to get Grunt all initialized. In my case, I ran “grunt” and received an error. It was in the “recess:dist” task, an Object has no method ‘toCSS’. Right, we need to set up Compass correctly.

If you don’t have Compass for Grunt already, you can install it:

npm install grunt-contrib-compass

Then we have to fix our Gruntfile.js a bit. grunt-recess is actually for LESS, so that won’t work very well with our SASS/Compass file. I comment out the entire “recess” code block, as well as the “grunt.loadNpmTasks(‘grunt-recess’);” from the “Load Tasks” section, near the bottom of the file, and finally commented out “recess” from the “Register tasks” section. Then I add “grunt.loadNpmTasks(‘grunt-contrib-compass’);” to the tasks list, and “compass” to the registerTask function.

Now, following the instructions for Grunt Compass, I copy over the Compass section of the initConfig and configure it to my settings:

compass: {
  dist: {
    options: {
      sassDir: ‘assets/sass’,
      cssDir: ‘assets/css’,
      environment: ‘production’,
      relativeAssets: true
    }
  }
},

This is basically working, except for two issues: There is an issue at the bottom of the SCSS file, the Media Query section contains some LESS variables, and these are undefined. For the moment, I comment those out. The second issue is that LESS was being compiled to a file called main.min.css, while SASS is compiling to app.css. I thought of creating a ‘main.min.scss’ file, and importing the ‘app.scss’ file, but that wouldn’t include Pure. So, instead, I will make use of grunt-contrib-cssmin

After installing it if you don’t have it already, add “grunt.loadNpmTasks(‘grunt-contrib-cssmin’);” to the tasks, and add ‘cssmin’ to the registered tasks, then I added this under my compass config:

cssmin: {
  combine: {
    files: {
      ‘assets/css/main.min.css': [
        ‘assets/css/pure/build/pure-min.css’,
        ‘assets/css/app.css’
      ]
    }
  }
},

And now I can run Grunt successfully, with Pure CSS being loaded first, and my SASS/Compass file afterwords. We’re basically ready to go, other than changing some classes in the template files from Bootstrap to Pure classes.

One final thing we can do is fix the “watch” command, so when you type “grunt watch”, grunt will watch your SASS/Compass files, and compile and concatenate them after any changes. I added this code after the “js” block in the “watch” code block:

sass: {
  files: [
    ‘assets/sass/*.sass’,
    ‘assets/sass/*.scss’
  ],
  tasks: [‘compass’, ‘cssmin’, ‘version’]
}

This should be a decent base to start from. It was actually quite a bit of work… I may just fork Roots or see if I can add a branch that will stay updated with Roots updates but use SASS and Pure. I have a feeling I will be using this again in the future.

Well that’s all for now, it turned out to be a little long, but hopefully beneficial to some. Let me know if I can improve it or if you’d do something differently. I’m relatively new to Grunt as well so I’m sure that improvements can be made, and I should also update the “package.json” file to include the new npm packages.

Why do we do this as web developers? Why put so much extra code in place for a simple website?

Because going back to a website without any CMS means that every page needs to be edited individually. Adding a script to the header or footer? Yeah, copy and paste that throughout the site if the header and footer isn’t shared. Normally on older sites it’s not. Even if PHP was used.

It’s also true that a bad developer can butcher and completely misuse a CMS so all the benefits of it are shattered. But hey… best we can do is work with what we have. I know that I try my best to implement best practices.

Anyways… my advice for today is: if you haven’t used a CMS or framework before (which means you are probably doing your sites in straight HTML and CSS), that’s fine, but by all means… get on it. Yes, you’ll need to learn some PHP, but not necessarily all that much. And trust me… it’s worth it. Sooooo worth it.

Alright, so I embarked on setting up PHPMyAdmin on Arch last night. On Debian/Ubuntu, it’s apt-get install phpmyadmin, and normally after installation, you can log in at http://kalenjohnson.com/phpmyadmin, right?

Of course, the Arch way is “simple”, and by simple, they mean unconfigured and unlinked. Don’t get me wrong, I completely understand what “Simple” means to Arch, and I like it and the idea. It does tend to mean learning everything though. How to install, configure, and set up every. piece. of. software. installed. And sometimes it seems like there are added steps not included in the original installation. Take this for example:

Arch Linux’ version of phpMyAdmin includes an .htaccess file. After I had followed the wiki, copied config files over from the phpMyAdmin installation, I was getting the a “Permission Denied” page when trying to load phpmyadmin in the browser. At first I thought it was a root folder permission issue, but I wasn’t about to go messing with folder permissions. Then I find the .htaccess file in /usr/share/webapps/phpMyAdmin simply has “deny from all”. The wiki page does say to change this, but my question is, why is it there in the first place? It doesn’t seem like a security issue if you change it during setup.

I don’t know, I’m starting to wonder about ol’ Arch. Yes, you definitely get to know your system, and build it from scratch. But when you have to do simple mundane things like this for no apparent reason, I begin to second guess. Other distro’s at least do their best to have things set up when you install a program so that you don’t have to copy around config files and change code unnecessarily.

*shrug*, I guess this post was more of a rant than anything else.