As a result of the EAV data structure in Magento, the options of a select or multiselect attribute are stored and retrieved by id. This poses a challenge when getting the attribute in that calling getAttName() or getData('att_name') on an object (product, customer, etc.) will return the id instead of the text value that may be expected. This is easily addressed by Magento with the method getAttributeText('att_name') which will return the text string.

Note: In the methods mentioned above "AttName" and "att_name" would be replaced by the attribute name. For instance, a "Button Count" attribute would be retrieved with getButtonCount() or getData('button_count').

On the other side, there are times on the backend when you may need to find the attribute's value id from it's text, for instance to store or add it to a new product. This takes a bit more effort, but is still relatively easy. You will need to inject Magento\Eav\Api\AttributeRepositoryInterface into your class. A minimal example using our "Button Count" attribute would be:

class Example
{
    /**
     * Attribute repository
     * 
     * @var \Magento\Eav\Model\AttributeRepository
     */
    protected $attributeRepository;

    public function __construct(
        \Magento\Eav\Api\AttributeRepositoryInterface $attributeRepository
    ) {
        $this->attributeRepository = $attributeRepository;
    }

    public function getButtonCountOptionId()
    {
        $attribute = $this->attributeRepository->get('catalog_product', 'button_count');
        return $attribute->getSource()->getOptionId('Three Buttons');
    }
}

Our getButtonCountOptionId() method would return a string containing the ID associated with the "Three Buttons" select option, such as '234'.

Note: When we inject and instantiate the interface Magento\Eav\Api\AttributeRepositoryInterface we will get an object with the class Magento\Eav\Model\AttributeRepository. This is due to the preference set by the Magento Eav module in Magento\Eav\etc\di.xml.

Referenced Files
Magento\Eav\Api\AttributeRepositoryInterface
Magento\Eav\Model\AttributeRepository
Magento\Eav\etc\di.xml

Photo by Olia Gozha at Unsplash

Vagrant is an indispensable part of my development tool belt for quickly spinning up a local environment on Mac OS X. When used with VirtualBox, it provides cheap, easy, disposable servers that alleviate any fears of breaking something or catastrophic loss.

At it's heart Vagrant is simple to configure and run, but can become increasingly overwhelming as your needs grow more and more complex. While provisioning tools such as Chef, Puppet, SaltStack, and Ansible help with complexity, they aren't necessary for, and at times hinder, "quick and easy" setups. We will ignore them here.

Let's create a simple, modern LEMP stack utilizing the following components:

• Ubuntu 14.04
• Nginx 1.8.x
• MySQL 5.7
• PHP7

We will build the server via the command line in order to remove any cruft between ourselves and the machine, facilitating a more innate understanding of the process.

Note: These instructions are purposefully limited in scope to support ease of use, ignoring most configuration, security, and best-practices commonly utilized on a production server. This is fast and loose.

Vagrant and Ubuntu 14.04

Let's begin by installing Vagrant onto the machine we are working from. Visit the downloads page and perform the installation.

Additionally, Vagrant uses a provider which performs the actual virtualization of the environment. Two common providers are VirtualBox and VMWare. We will use VirtualBox for the reason that it is free. Visit this page, download the software, and perform the installation.

With Vagrant and VirtualBox successfully installed it's time to move forward. Let's create a directory to hold the required files. Open your console of choice and run the following commands:

$ cd ~/Documents
$ mkdir MyVagrant && cd MyVagrant
$ mkdir html

Note: The final command above creates a MyVagrant/html directory which will be used later. You can ignore it for the moment.

Now, with a few more simple commands, we can immediately build and start a virtual Ubuntu 14.04 machine.

Note: You will be downloading a base box for the first time, which may take a while to complete. Boxes only need to be downloaded once, and can then be reused on many virtual machines.

$ vagrant init ubuntu/trusty64
$ vagrant up

Once vagrant up is executed, your virtual machine is using space and resources on your computer. At any time you can remove the virtual machine by running vagrant destroy and free up the used space and resources. Need the machine back? Simply run vagrant up again.

Note: For a full list of vagrant commands, visit this page.

At this point, you can execute vagrant ssh and you will be automatically SSH'd into the virtual machine. Go ahead and explore. Once you are done looking aound, simply logout.

As noted in the console, vagrant init created a Vagrantfile. This file holds the instructions used to build the base environment. Using your text editor of choice, take a moment to investigate the Vagrantfile and it's configuration options.

Note: You can create as many Vagrantfiles as you want, provided they are in different locations, but be aware that any vagrant ... commands must be executed in the directory containing the Vagrantfile you want to reference. In our case, since we are in the MyVagrant directory, the vagrant ... commands are using that Vagrantfile.

Let's make and implement a few changes to our current Vagrantfile. Using your text editor, find the following line:

# config.vm.network "private_network", ip: "192.168.33.10"

And uncomment it:

config.vm.network "private_network", ip: "192.168.33.10"  

Then find the line:

# config.vm.synced_folder "../data", "/vagrant_data"

Uncomment and edit it to read:

config.vm.synced_folder "html", "/var/www/html"  

Note: Both edits to the Vagrantfile above will come in to play shortly when we introduce Nginx, but recognize that the first argument of config.vm.synced_folder is in reference to the html directory we created earlier.

With those changes made, save the modified Vagrantfile and execute vagrant reload on the command-line. This will implement our edits and restart the virtual machine.

Nginx 1.8.x

With our virtual machine up and running, let's install our first component, Nginx. Begin by logging in to the machine using vagrant ssh.

Let's use the most recent stable version of Nginx and since the default Ubuntu repository has a slightly out-of-date version, we need to start by adding an additional repository. To do so, execute the following commands:

$ sudo add-apt-repository -y ppa:nginx/stable
$ sudo apt-get update

Once those commands have completed successfully, we can install Nginx.

$ sudo apt-get install -y nginx

After the installation is complete, we should have a fully functioning web server. Test this out by visiting http://192.168.33.10/. You should see the default Nginx welcome page. Additionally, if you look in the MyVagrant/html directory, you should see a new file called index.nginx-debian.html.

But where did that URL come from? And the HTML file?

The URL was set when we edited config.vm.network in our Vagrantfile. We set private_network to an ip address of 192.168.33.10.

The second edit we made was to config.vm.synced_folder and we synced html to /var/www/html. The first argument is the folder on our local machine relative to the Vagrantfile and the second argument is the folder on our virtual machine. The syncing gives us access to our virtual machine through our local filesystem. In our case, /var/www/html is the default web root for Nginx and we can get access to those files via the local html folder.

If you closed it, re-visit http://192.168.33.10/. Now open up MyVagrant/html/index.nginx-debian.html and make a change. Modify some text, change a style, anything you'd like. Save your edits and then refresh that page in your browser. You should see your changes immediately reflected! As you can see, synced folders are a powerful feature of Vagrant.

We won't get any deeper into Nginx, but you can explore it's configuration on your own.

MySQL 5.7

Most websites need a data store. MySQL is an immensely popular option, and one that is quite easy to install. If you aren't still, log back in to the virtual machine using vagrant ssh.

Again, the Ubuntu repositories hold an older version of MySQL. As such, we need to take a few extra steps to get access to MySQL 5.7. Run the following commands first:

$ wget http://dev.mysql.com/get/mysql-apt-config_0.3.5-1ubuntu14.04_all.deb
$ sudo dpkg -i mysql-apt-config_0.3.5-1ubuntu14.04_all.deb

You will be prompted to set some configuration options. On the initial screen select Server and hit return. Then arrow down to select mysql-5.7-dmr and hit return. Then, again, arrow down to Apply and hit return. You will then be returned to the command-line. Continue with:

$ rm mysql-apt-config_0.3.5-1ubuntu14.04_all.deb
$ sudo apt-get update
$ sudo apt-get install -y mysql-server-5.7

You will be prompted to input and confirm a password for the root user. Once installation is complete, you can access MySQL with mysql -u root -p. You will be asked for the password which you just created and once you are authenticated, you can interact with MySQL using it's command-line interface.

PHP7

Finally, let's install PHP7, the newest version. It's fast. Almost twice as fast as the previous version, 5.6 (mileage may vary of course). Once again, let's add a repository in order to get version 7.0 and install the package.

$ sudo add-apt-repository -y ppa:ondrej/php
$ sudo apt-get update
$ sudo apt-get install -y php7.0-fpm php7.0-cli

Depending on your application and use-case, you may need to add some PHP extensions. For instance, since we just installed MySQL, let's install that extension.

$ sudo apt-get install -y php7.0-mysql

Not all extensions have been upgraded for PHP7, although the majority of them have. If you are in doubt, check this resource.

We also need to make a few changes to the Nginx configuration in order to a) serve .php files, and b) use PHP7. On the virtual machine edit the file /etc/nginx/sites-available/default. For instance, run sudo nano /etc/nginx/sites-available/default. We need to edit the following lines to add index.php. Change:

# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;  

to:

# Add index.php to the list if you are using PHP
index index.php index.html index.htm index.nginx-debian.html;  

We also need to uncomment and edit a few lines of a location block. Look for:

# location ~ \.php$ {
#     include snippets/fastcgi-php.conf;
#
#     # With php5-cgi alone:
#     fastcgi_pass 127.0.0.1:9000;
#     # With php5-fpm:
#     fastcgi_pass unix:/var/run/php5-fpm.sock
# }

And change it to:

location ~ \.php$ {  
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
}

Exit and save the changes, then restart Nginx.

$ sudo service nginx restart

If you visit http://192.168.33.10/ again, you should see no change, but it should still work. Let's create a simple .php file to test PHP. in our MyVagrant/html directory, create a file index.php and add this line:

<?php phpinfo(); ?>  

Save the file, and revisit http://192.168.33.10/. You should now be greeted with the the default PHP info page.

Conclusion

Throughout this tutorial we have managed to install Vagrant and VirtualBox and spin up a quick Ubuntu 14.04 virtual machine. Then we were able to install the following components:

• Nginx 1.8.x
• MySQL 5.7
• PHP7

With a few small configuration changes we successfully served a PHP page and edited files in our web-server root via the synced MyVagrant/html folder on our local filesystem.

Photo by Paul Itkin at Unsplash

Anyone that has dealt with Magento 1.x in the past no doubt has the war stories and scars to prove it. I am no different. It's a beast and I've sworn it off. Again and again. But with e-commerce, I've found it to be a circular argument. A recent project has brought me to the doorstep of Bigcommerce and I lament the drawbacks it has, and then I long for my Shopify days, and then, once again, ponder the power of Magento (plus, we're at version 2). I pop from one to the other, around and around, never satisfied or completely won over. I suppose there is something to be said about life in that statement, but no matter.

Since my previous build of Magento 1.8.x a year or two ago I have improved immensely as a developer and have continued to grow and refine these skills. Now, it is far less of a chore to spin up a quick box and test something out. It wasn't always that way for me, and in those times I relied on the community and those resources to help get me through. Here's a bit of return on that. I hope this small tutorial can get someone else through and perhaps connect a few dots. So let's start with our box.

Note: This should only be used for testing and playing. Nothing here is production ready, hardened, or best-in-class!

Note: If you are looking for a simple, modern LEMP stack, see my article Simple, Modern LEMP Using Vagrant.

Vagrant and Ubuntu 14.04

Let's begin with spinning up a bare-bones Vagrant box using Ubuntu 14.04. The Vagrantfile below will get you started, but feel free to modify it as you please. Also note that this step is optional. If you have a bare-bones Ubuntu 14.04 box, you can use it in place of this one.

Vagrant.configure(2) do |config|

    config.vm.box = "ubuntu/trusty64"
    config.vm.network "forwarded_port", guest: 22, host: 7842

    ## Set the IP below to your own, and edit your hosts file if you'd like
    config.vm.network "private_network", ip: "192.168.56.102"

    ## Feel free to modify the hostname below
    config.vm.hostname = "magento.vm"

    ## Modify the path below to your synched folder
    ## The path below is relative to this Vagrantfile
    config.vm.synced_folder "../source/magento/", "/var/www", type: "nfs"

    config.vm.provider "virtualbox" do |vb|
        # Customize the amount of memory on the VM:
        vb.memory = "4096"
        vb.cpus = "4"
        vb.name = "magento"
    end

end  

Go ahead and spin that up on the command line.

$ vagrant up

Let’s Install PHP7

Once you have a bare-bones Ubuntu server to SSH into, go ahead and do that.

$ vagrant ssh

Now that you are in the server, let's run a few commands to set up PHP7. A lot of these steps are from a great DigitalOcean article covering the same topic. Reference it for a more in-depth explanation. We need to begin by adding a repository to use with apt-get in order to install PHP7.

$ sudo add-apt-repository -y ppa:ondrej/php
$ sudo apt-get update

Once the repository is added and we have updated apt-get, let's install the package and the necessary PHP extensions that Magento2 requires (it's a long list).

$ sudo apt-get install -y php7.0-fpm php7.0-mysql php7.0-cli php7.0-mcrypt php7.0-curl php7.0-gd php7.0-intl php7.0-xsl php7.0-zip php7.0-mbstring

That should complete without issue and once you are done you can run php -v, and you will see something resembling:

PHP 7.0.4-1+deb.sury.org~trusty+1 (cli) ( NTS )  
Copyright (c) 1997-2016 The PHP Group  
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies  
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies  

With that, we have PHP7! Now on to Nginx.

Serving with Speed

A quick note on why Nginx. I have found it to be fast, especially with Magento. That's it. I am not interested in much more than that in this case. So let's get it installed. Again I am using an additional repository in order to get the most recent stable version of Nginx (1.8.x at this time).

$ sudo add-apt-repository -y ppa:nginx/stable
$ sudo apt-get update

And install.

$ sudo apt-get install -y nginx

Congratulations, grab a beer! You should be able to visit the IP address from your Vagrantfile (192.168.56.102 in this tutorial) and be greeted with the default Nginx Welcome page.

Sneak a Quick One In

We are going to need MySQL for the Magento installation as well, and since there isn't much to getting that going, just run the following command to install it and set the root password.

$ sudo apt-get install -y mysql-server-5.6

While we're here, let's just quickly set up a database for Magento which we will need a bit later. Go ahead and drop in to MySQL.

$ mysql -u root -p

And on the MySQL prompt, enter:

create database magento;  
exit;  

Stay Composed

We are going to need Composer to run our installation of Magento via the command line. Let's run a quick installation of that as well.

$ sudo curl -sS https://getcomposer.org/installer | php
$ sudo mv composer.phar /usr/local/bin/composer

Stay Secure

One semi-final server-side command. Let's pop in a self-signed certificate so that we can reach the admin side of Magento over https.

$ sudo mkdir /etc/nginx/ssl
$ sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/nginx/ssl/magento-self.key -out /etc/nginx/ssl/magento-self.crt

Wow, okay, maybe another sip of beer. Take a breath and get ready, because now, finally, we get to Magento.

The Payoff, Step 1

As a glutton for punishment, I opt to install Magento2 entirely from the command line using Composer. As such, we need to secure a, ahem, secure key from Magento Connect to do that. Visit this link, log in to, or create, your account and follow the instructions. We will need to reference this key shortly.

Key in hand, let's continue. Navigate to the /var/www directory on the server. There will be a folder named html which holds the default Nginx page we celebrated earlier with our beer, but we will ignore that. From here we will run composer to download the Magento2 CE Metapackage into a new folder called magento.

$ composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition magento

You will immediately be prompted for your username. This is where we need the key we just created. Your username is the "Public Key" and the password is the "Private Key." You will be prompted as to whether you want you're credentials stored. Feel free to answer yes or no, but I suggest yes. After that… wait for Composer to do its thing. It will be a little bit, you may want some more of that beer. Perhaps a second. This is Magento after all. At the end of this, you should have a folder /var/www/magento.

But Wait!

Towards the end of the Composer install above, the command line may say "Could not fetch…"! Don't worry, just follow the provided instructions, but you will need a GitHub account. And we're back on track.

The Payoff, Step 2

Can you feel that? We're nearly there. Let's blindly set some permissions and ownership. Keep in mind that this is a test install and blindly copying and pasting commands to change permissions and ownership is not always prudent. In this case, let's go for it. Navigate to /var/www/magento and paste the following commands:

$ chown -R :www-data .
$ find . -type d -exec chmod 770 {} \; && find . -type f -exec chmod 660 {} \; && chmod u+x bin/magento

Note the period (".") at the end of the first line. Make sure that is included. These commands will take a little time to run in order to iterate over all the files and folders.

Now the cool part. Navigate in to the /var/www/magento/bin folder and let's run a command. This command is quite long and has a lot of options in it. Replace the all-cap placeholders with your own information.

./magento setup:install --base-url=http://YOUR-IP-OR-URL/ --db-host=localhost --db-name=magento --db-user=root --db-password=YOUR-MYSQL-ROOT-PASSWORD --admin-firstname=YOUR-FIRST-NAME --admin-lastname=YOUR-LAST-NAME --admin-email=THE-ADMIN-EMAIL --admin-user="THE ADMIN USERNAME" --admin-password=THE-ADMIN-PASSWORD --language=en_US --currency=USD --timezone=America/New_York --use-rewrites=1

And with that, we have Magento2! Note the URI at the end of the above command which denotes the Admin URI. We will need that to log in to the Admin section of our installation.

So go ahead and visit that IP or URL we have from the Vagrantfile.

Wait, What!?

Still see the default Nginx landing page? Sure do! We have two final steps to get this guy into working order. The first is the Nginx config file, and finally, we implement a quick cron job.

Config, Config, Config

Let's bang this out and get going. I’ll leave the details out of it, but run the following command to edit our default site config:

$ sudo nano /etc/nginx/sites-available/default

Delete everything that is in there, and replace it with the following (again, replace the all-caps with your information):

upstream fastcgi_backend {  
    server unix:/var/run/php/php7.0-fpm.sock;
}

server {  
    listen 443 ssl;
    server_name YOUR-IP-OR-URL;
    set $MAGE_ROOT /var/www/magento;
    set $MAGE_MODE default;
    ssl_certificate /etc/nginx/ssl/magento-self.crt;
    ssl_certificate_key /etc/nginx/ssl/magento-self.key;
    include /var/www/magento/nginx.conf.sample;
}

server {  
    listen 80;
    server_name YOUR-IP-OR-URL;
    set $MAGE_ROOT /var/www/magento;
    set $MAGE_MODE default;
    include /var/www/magento/nginx.conf.sample;
}

Now hit Nginx with a restart sudo service nginx restart and now you should be able to visit your IP or URL in the browser and be greeted with Magento2!

Cron, Cron, Cron

With our front-end up and running, take a peek at the Admin side of things. You can append the admin URI you noted at the end of the Magento installation and use the info you entered in that extra long Magento install command. You should be able to log in without problem, but you will see a warning immediately.

One or more indexers are invalid. Make sure your Magento cron job is running.  

Well, fact is, that cron job is not running! Let's make it run. Enter the following command.

Note: The user below is specific to Vagant, so if you aren't using Vagrant, enter the user that Magento is running under.

$ sudo crontab -u vagrant -e

Choose your editor of choice and then enter the following after the comments in the file:

*/1 * * * * /usr/bin/php -c /etc/php/7.0/cli/php.ini /var/www/magento/bin/magento cron:run > /var/www/magento/var/log/magento.cron.log&
*/1 * * * * /usr/bin/php -c /etc/php/7.0/cli/php.ini /var/www/magento/update/cron.php > /var/www/magento/var/log/update.cron.log&
*/1 * * * * /usr/bin/php -c /etc/php/7.0/cli/php.ini /var/www/magento/bin/magento setup:cron:run > /var/www/magento/var/log/setup.cron.log&

And that, my friend, is it. If you refresh the Admin side, the cron warning should be gone and you are the proud owner of a Magento2 installation. And now that you have all the information to get back up and running, feel free to blow this one up! Explore, change, break and see what’s under the hood. There's a lot to know.

Photo by kazuend at Unsplash

A common feature request, and the subject of a multitude of workarounds and hacks, has been for a featured image in Shopify blog entries. This has historically been solved with your common Shopify hacks: add the image as the first item in the text and pull it out dynamically, use metafields, name the image with the id of the blog entry, etc.

It seems that Shopify has listened as a new field has shown up when you create a blog entry. The new field works as expected, and now adding a featured image to an entry is a simple task.

To use that image within your Liquid templates took a bit more digging, but it is syntactically as you would expect:

<img src="{{ article.image | article_img_url: 'master' }}" />  

As with other image tags, you can specify various image sizes ('master' above) within the URL filter.

Photo by Natasha Vasiljeva at Unsplash

I’ve been developing a page that gets loaded with multiple instances of the WYSIWYG text editor Summernote. An issue arose when the user attempted to remove a node which contained a Summernote instance. The jQuery .remove() method was attached to a button, which would remove the node that contained the Summernote instance. When the form was submitted, I would get an error:

Uncaught TypeError: Cannot read property 'val' of undefined  

I couldn’t track down the root of the error, but Summernote was looking for a val() that it couldn’t find. The correct node and child elements had been removed from the DOM, but Summernote seemed to think it was still there. I tried the .destroy() method of Summernote before the jQuery .remove() to no avail. In the end, I ended up using the jQuery method .detach() instead of .remove() which “keeps all jQuery data associated with the removed elements.” On submission, Summernote acts correctly and, since the DOM node had been removed, my data persisted correctly in the back-end.

Photo by Cameron Kirby at Unsplash

While implementing a range slider input for a recent project I needed headings for the three available stop-points, one left-aligned, one centered, and one right-aligned. After a bit of verbose HTML and CSS, I refined it several times and settled on the following code.

CSS

.ranges {
    text-align: center;
}

.ranges span:first-child {
    float: left;
}

.ranges span:last-child {
    float: right;
}

HTML

<div class="ranges">  
    <span>Left</span>
    Middle
    <span>Right</span>
</div>  

Photo by Elliott Engelmann at Unsplash

I’ve been building out a recent project, Jazzleadsheets.com, on AngularJS and Magento being served by Nginx, and ran into a frustrating problem. When I refreshed any page other than the index, the site would throw a 500 Internal Server Error. Additionally, if I entered in a nonsense URL, which should be directed back to the homepage, I received the same 500 error. I was stumped.

After fruitless hours researching and testing, I made a breakthrough. I realized that in my application config I implemented “HTML5 Mode” with:

.config(['$locationProvider', function($locationProvider) {
    $locationProvider.html5Mode(true);
}])

This allowed me to dump the hash-bang syntax (example.com/#/catalog) and present the user with well-formatted URLs (example.com/catalog). This was also the root of the issue. Commenting out the code segment above resulted in hash-bang URLs, but allowed me to refresh any page correctly as AngularJS knew how to route those. From there I put the pieces together and realized that Nginx was configured correctly to route the requests for AngularJS. The answer lie in a single addition to my Nginx location block:

location / {  
    ...
    try_files $uri /example.html;
    ...
}

Where example.html is replaced by the base file you want to route requests to. In my case, index.html. With this addition and a quick restart of Nginx, my page refreshes worked like a boss.

Photo by NASA at Unsplash

It’s common knowledge that Magento can be a bit of a beast to modify and customize. On a recent project I wanted to add a custom field to the admin side of a product, which is a simple process, but I also wanted to reorder them within the tab. My custom field needed to come after the "Name" field, not at the end (after "Country of Manufacture") of the options. Simple request, simple execution, but hours of searching for the answer.

Question: How do I reorder the admin fields within the "General" product tab?

Answer: Magento orders these fields according to a sort order pulled from the database. With all the foreign keys and EAV structure this took quite a while to track down. Ultimately, the table you need to modify is named eav_entity_attribute, but you need to first find the ID of the element you would like to change. This can be found in the eav_attribute table and is called attribute_id. Once you have that number, you can navigate to the eav_entity_attribute table and find the ID in the attribute_id column. Make note of the attribute_group_id as these are the other elements that are in the tab in the admin section. By default there are 29 elements, plus the one you added, and you will notice the sort_order column. Your custom element will have the value of 30 (if this is the first custom attribute you added to Magento) and is thus last in the sort order. In my use case above, I wanted my custom attribute to be after the "Name" field which means setting the value of the sort_order field to 2. Before you make the change, you need to make a space for it, so you need to increment every value in sort_order by 1 starting from the value you want your element to be. This is easily accomplished with the MySQL query below:

UPDATE eav_entity_attribute SET sort_order=sort_order+1 WHERE attribute_group_id = 7 AND sort_order > 1  

Make sure that the value in sort_order > 1 is set appropriately for your own placement. Since I want my custom element to appear second, I need to update the values for 2 through 30. The sort order is now appearing as 1, 3, 4, 5, 6, etc. which leaves the spot for my custom attribute. Now, it’s merely a fact of changing the sort order value for my element from 31 to 2! If you go back to the admin page and refresh, your custom attribute should appear in it’s correct place.

Photo by Paul Itkin at Unsplash

It took me quite a while to get all this information together and working. Instead of enduring the search over again, I am writing it down for myself and any others that may find it useful.

1) Visit Ryan Florence’s site for the bulk of the info.
2) When you add the web-server’s repository, and this is specifically for MediaTemple GridServer users, the SSH url should be:

ssh://serveradmin%mt-example.com@mt-example.com/home/#####/domains/mt-example.com/html/  

where ##### is the GridServer cluster you are hosted on.

Photo by NASA at Unsplash