Last Saturday I finally had the time to get Pure Salt Gaming up and running. To start there are a few products for sale including pre-orders for jerseys which I designed myself:
On top of that I am looking to partner with content creators, streamers, and free agents. For now Pure Salt Gaming is really only interested in Chess, Destiny 2, and Halo; yet we'd also be potentially interested in individual based eSports such as Smash or Street Fighter players.
Since this is my personal blog with a focus on development I think it's fitting to get a rundown on the current setup. With years of experience in Magento before 8 years away from PHP professionally I was hoping that there would have been a new ecommerce solution outside of Magento or WooCommerce. Magento 2 existed yet there wasn't anything else I could find in any language that would have delivered an experience closer to working on an Express or Symfony based projects. So it looked like Magento 2 it was.
From there I setup an environment for Magento 2, started reading up on all the changes, and then began tinkering around in it. Still felt like the Magento that I last used back in 2012 to mixed feelings as I began to realized that it would need a module for blogging or have a separate site setup for that. Which would end up being either the blog I wrote for this site or utilizing WordPress. Neither options seemed great so acquiring or writing a blog module seemed to be the solution.
So, although I had my solution life and quarantine ended up getting in the way. Daycares closed as well as my wife's office as well as mine going remote really made it hard to cut out time to work on side projects. To add to that the side project time was completely consumed by schooling where one of my Operating Systems homework assignment of 1500 words was double what my English final essay word count. As you can see I was quite busy and Magento 2 wouldn't have been a fun distraction.
Eventually meeting someone from the keyboarding community (more on that in another post) he showcased a friend's site he helped with for a keycap set: https://www.ashkeebs.com/product/infinikey-port/. Looking through the source code I saw it was actually WordPress with WooCommerce; something I dismissed early on in my design choice. The early dismasle is 100% due to my bias against coding in WordPress. I admire it for what it does and how it works it's still hard for me to get around working 2003 style PHP where PHP and HTML freely mingle with each other. Yet, as we conversed more I finally decided to give it a shot and see how it would go.
Thus only four days later, Pure Salt Gaming was officially online with shipping, payment processing, and blogging all within a single WordPress app. Where I scoffed at the simple design of WordPress is also the spot that lead to an extremely quick ramp up. It took more lines of CSS than PHP to get the site working as intended and both of those line counts were quite small around 600 and 500 respectfully. I'm still not a fan of code like the one below, yet clients are never going to see it anyways so the only person that cares how it looks is me!
<?php
add_action('storefront_header', function () {
if (!storefront_is_woocommerce_activated()) {
return;
}
$cart = WC()->cart;
?>
<ul id="account-menu">
<li<?= is_account_page()
? ' class="current-menu-item"'
: '' ?>>
<a href="<?= esc_url('/my-account'); ?>"
title="<?= esc_attr_e('View your account', 'storefront'); ?>">
<i class="fas fa-user"></i> Account
</a>
</li>
<li<?= is_cart()
? ' class="current-menu-item"'
: '' ?>>
<a href="<?= esc_url(wc_get_cart_url()); ?>"
title="<?= esc_attr_e('View your shopping cart', 'storefront'); ?>"><i
class="fas fa-shopping-cart"></i> <?= $cart->get_subtotal()
? $cart->get_cart_total()
: '<em>Empty</em>'; ?>
</a>
</li>
</ul>
<?php }, 25);
Now we have our WordPress up and running alongside of installing WooCommerce we were left with template designs. To keep things quick and easy I stuck with WooCommerce's default template, Storefront, and just created a child template based off of that. My functions.php
file was simple in implementation in order to separate the different overwrites necessary for the new child theme:
<?php
/**
* @package salty
*/
require 'action.php';
require 'filter.php';
require 'overwrite.php';
As the names imply, action.php
handled all of the *_action
based methods; filter.php
did the same for *_filter
methods; overwrite.php
took care of any sf_*
functions that would need to be overwritten such as storefront_site_title_or_logo
. The other overwrites follow the standard WordPress and WooCommerce methodology of having the file of the same name in our themes directory so no need to get into that.
On the frontend side, I tried to keep the CSS as generic as possible utilizing em
when I could yet eventually I did start heavily relying on px
and !important
in specific cases. That left me with about 60 rule definitions, 57 !important
statements, and 44 px
statements which I can live with. Besides, most of those !important
statements were to remove margins and paddings. I had already done the logo, design choices, color scheme, and even the products at the end of 2019 so that helped speed run the frontend. Lastly, the product pictures were done by Steve Freeman, who does awesome photography, and untouched for now.
One last detail about the implementation, I still used GitHub for the entire code base. I'm not 100% certain on which sub directories WordPress/WooCommerce needed for write permissions so on the server it's just owned by www-data
and any time I need to do a git pull
I setup a bash script to chown $github_user $directory
-> cd directory
-> git pull as $github_user
-> cd ../
-> chown $www_user $directory
. There's a similar script for pushing if WordPress, WooCommerce, or any plugin is updated on the server side. Probably not best practices yet simple enough and I felt fitting for the WordPress mentality of partying like it's 2003.
Yes! Some of my choices were based off of recommendations from my keyboarding friend while others based off of what I needed to use. From his recommendations I went with W3 Total Cache to handle all caching of everything in Memcached, Yoast SEO, and Easyship for shipping prices. There were some other generic plugins added such a contact form, product addons, and analytics. Did also add Printful to start adding smaller runs for shirts and hoodies instead of having to bulk order products from a printer.
One major caveat though! Easyprint was showing exorbitantly high prices for users before they added their mailing addresses! One jersey that ways barely anything? No problem, we'll deliver it by a golden chariot for only $300! That was a big yikes yet after doing some digging found out that it was based off of the default shipping zones that WooCommerce gathers. I had checked Hide shipping costs until an address is entered
thinking that meant it would hide for everybody however WooCommerce considered default geolocated zones counted as an address. To fix the issue I just had to change: WooCommerce -> Settings -> General -> Default customer location
to No location by default
and that successfully did what I expected the other flag would have done.
If you read through any of this then thanks for taking your time out of your schedule in order to read on. If you have any questions or feedback feel free to hit me up on Twitter. Also it would be pretty rad if you could help support Pure Salt Gaming by interacting with the site or any of the media pages:
Thanks again and take care!
Greetings, I'm John Mullanaphy and currently creating stuff at Impact.com as a Senior Principal Software Engineer. When I'm not coding there then I'm usually found toying around on GitHub or creating comics at Boycott Paper.
Outside of the programming world you can probably find me on the mats rocking a purple belt at Marcelo Garcia Academy, streaming on Twitch, or playing some chess.
Feel free to message on Threads if you have any questions or requests. Please help yourself to my printable résumé as well!