Embedding Scripts and Tags into the Magento 2 Header

What do Google Tag Manager, a Facebook Pixel, and a Twitter Pixel all have in common? They all have to be embedded in the Magento header to function properly, and Magento 2 made that just a little bit harder to do.

To embed a custom script in the Magento header, log into the Magento admin and go to Content >> Configuration(Under Design) >> and select “Edit” next to your store view theme. From here, you’ll see a screen that looks something like this –


Click on “HTML Head” and scroll down to the section that says “Scripts & Style Sheets”. From here, embed your code, and save.

Once that’s done, you may need to flush the Magento cache to get it to show up on the frontend. To do that, navigate to System >> Cache Management(under Tools). There you can select all, and then hit “Submit” next to the “Refresh” drop-down.




New Years Resolutions – Refer a Friend – Get $100 on Amazon

Refer a friend today & get $100 on Amazon after their first payment of $100 or more! Contact sales@grizzlysts.com for more information. Valid through January 31st.

Fields marked with an * are required

Using the Ticket System

Priority Levels

Synthia is designed with configurable priority levels to allow for customization in your environment. The enabled defaults are “High”, “Medium”, and “Low” which will work for most users. This option can be accessed via Support >> Ticket Priorities. To add one, click “Add Priority Level” and fill in the name. You also have the option to disable, enable or delete priority levels if they’re no longer required.

SMTP Configuration

In order to receive ticket notifications and have them sent to the customer, you’ll need to configure SMTP. Our recommended configuration is via SSL to your provider though it’s understood that it may not be an option in all environments. To configure SMTP, navigate to Configuration >> Email Settings. Here you’ll need to fill in your Email, Password, SMTP host, and IMAP host.

Click here to view Advanced SMTP Configuration.


Finally, Support >> Tickets will take you to the ticket queue. The “eye” on the right will let you view the ticket. The small “person” icon will bring up staff assignment, and the “stats” icon changes ticket priority. The red trash can, of course, is “delete”.

Creating Plugins for Synthia

Synthia was designed with simplicity and extensibility in mind and we’ve tried to show that best in its plugin architecture. Plugins are contained in application/modules and have a standard MVC structure, with folders named simply “models”, “views”, and “controllers”. You’ll also notice that Synthia is based on Codeigniter and most of the default Codeigniter documentation will be relevant, with a few exceptions. I’m going to demo a small plugin here that will handle a basic data pull and pagination.

The first class will be in a Pagination.php file and will be placed in the “controllers” directory inside your new module folder. You’ll notice we’ve got a constructor and then a single function, countryList(), that’s actually responsible for rendering the page.

class Pagination extends MX_Controller{

public function __construct(){

public function countryList(){
$rows = $this->pagination_model->rowCount();
$config['base_url'] = base_url() . "pagination/countryList";
$config['total_rows'] = $rows;
$config['per_page'] = 10;

$pageMaxItemId = $this->uri->segment(3) ?? 0;
$data['countries'] = $this->pagination_model->getCountries($config['per_page'], $pageMaxItemId);
$data['pagination'] = $this->pagination->create_links();

render("pagination.page", "default.template", $data);


Further, you’ll notice we’re calling a function in pagination_model called “rowCount()”. The code for pagination_model is below and should be placed in a file called pagination_model.php in the “models” folder. The Pagination_model class simply reaches out to the Synthia database(loaded via $this->load->database()) and returns a list of rows. This table doesn’t actually exist in Synthia and is for demo purposes only.

class Pagination_model extends CI_Model{

public function __construct(){

public function getCountries(int $limit, int $offset){
$sql = "SELECT * FROM country LIMIT " . $limit . " OFFSET " . $offset;
$query = $this->db->query($sql);

if ($query->num_rows() > 0) {
foreach($query->result() as $row){
$data[] = $row;
return $data;

public function rowCount(){
$sql = "SELECT COUNT(*) as rows FROM country";
$query = $this->db->query($sql);
return $query->row()->rows;


Now, to actually display the page. You’ll notice in Pagination.php the final line is a “render” function. That render function takes three arguments, the page to render to, the template desired, and the $data variable you’ve put together. That render function is specific to Synthia and will combine one of the Synthia templates with a page of your own creation and your data to render the final page. Creating a pagination.page.php file in your plugin’s “views” directory will make it available to this function. A very simple page for our uses is in the rar file attached to this article. The $countries variable is pulled directly from the $data field we pushed in from the Pagination.php.

Finally, we need to map a page in Synthia to our module. To do this, open up application/config/routes.php and add a line that looks like the following:

$route['admin/pagination'] = 'pagination/countryList';

This method of route mapping isn’t ideal because it’s likely to be overwritten during updates. We’re working on a more modular way to add routes and will update this post once one is in place.

How do I handle logging in Synthia?

Synthia uses standard Codeigniter logging. The statement below will log to “application/logs” by default. The first parameter accepts any of the 3 values( ‘error’, ‘debug’ or ‘info’), while the second parameter accepts a String as your log message.

log_message($error_level, $error_message);

Whatever happened to Synthia?

The Synthia project has been floating around for the last couple of years and I’m ashamed to say we haven’t really met expectations. We were ridiculously close to a launch in 2016 when a security flaw forced us to re-evaluate the project’s status. After some deliberation, we chose to refactor the project and rebuild it from the ground up to be more stable, more secure, and far more modular.

Synthia will be launched in September of 2017 with a reimagined admin panel, a ticketing system, and a modular design allowing developers to add to the platform easily with a minimum amount of effort. The billing module will be launched later in 2017.

The master plan for this software is quite simple. The base version of Synthia will be permanently free to use and extend for your needs. Support will be available as a paid(though very affordable) service or as part of a hosted solution.

As we’re approaching launch, updates, documentation, and more product videos will soon be available. I’d like to thank everyone who’s supported and waited for this project and hope you’re looking forward to a project we’ve been very excited to build!

How to win at web development contracts

If I had to tell you the complaint I hear most frequently from clients, it’s normally something about their last developer and it tends to be somewhere along the lines of “I paid thousands of dollars and never saw a completed product” or “The finished product wasn’t what I wanted it to be” and I attribute that, largely, to the large block approach to both development and pay.

I’m sure you know what I’m talking about if you’ve ever commissioned a piece of software. You pay 50% of the total project price up front and fork over a long list of requirements. At the end of the project, you’re handed a product that probably does about ¾ of what you thought it would and you’re expected to pay the final half of the bill. You may not have had much input along the way or you don’t feel like the final product is what you wanted it to be, even if that’s what it was on paper.

These situations aren’t necessarily anyone’s fault and don’t have to come from bad contractors or bad clients. Often, the way these projects are structured leads them to failure before they get off the ground.

You see, when structuring a contract you have to look at what behavior that contract is really rewarding. When you choose a “Half now, Half later” payment approach, the incentive is to sell as many contracts as possible(the first 50%) and close as many contracts as possible with the minimal effort necessary to receive payment. Speaking purely from a numbers situation, a consultant “wins” in the short term when they can complete less than 50% of the contract while keeping payment or close a contract at 100% payment with as few features as possible.

Now, I’m not saying that everyone in the industry going to think in those terms or is out to do the minimum. What I am saying is that it can lead to asking good people to work against their own self interests in order to uphold their integrity. Whenever possible, aligning other’s best interests with your goals tends to lead to superior results.

So how do we do that? Well, my personal favorite is to push work from a project based approach to an hourly one but to do so with clear controls and milestones in place. To expound a bit there; Let’s say we’re talking about an E-Commerce site. Now we might normally spec out all the features and set a price at $10,000 for the full design but what if we quantified the expected hours for each feature. We’ll start with a data import, assuming you’re coming from another platform. Let’s say that data import should take about 10 hours but could take up to 20 or 25 with complications.

Now, if I were doing that import for you and you insisted on fixed price, I would set the price at a point where I could comfortably spend 25 hours because I don’t want to lose money on your website. If we’re working on an hourly basis, it’s a bit different. Let’s say we decide to work hourly with pay on a regular time line(say, weekly or every two weeks) and quote out that import at “10-25 hours”. I’m no longer betting on a time to completion because you’re paying hourly, and you’re no longer paying enough to offset my gamble. When the project actually does only take 10 or 15 hours, you haven’t paid for 25 and if it does take 25, I haven’t lost by under-bidding.

Taking a step back, there’s another clear advantage to this approach and that’s modularity in both compensation and work. If someone quotes a certain number of hours for a portion of a project, you have a clear yardstick to measure their progress. If you’ve paid for 10 hours of work on a 10 hour piece of the project, you should have a tangible piece of completed work in your hands for what you’ve paid. You can very easily asses how well the project’s going by looking at the completed milestones alongside hours to completion of various milestones.

Furthermore, if you’re on a “pay as you go” schedule, completed work is yours. Should you choose to take what’s been built half way through and walk away with it, there should be no argument from your developer about doing so. You’ve paid for their time, not the work done, and they’ve been compensated fully. There’s never a situation where they feel like they own your project because there’s only been a partial payment and you’ll know about problems sooner because you’re paying for time as its accrued.

As I propose hourly billing, I can hear some people saying it can’t work because there’s no incentive not to let costs balloon. I won’t lie, there is some truth to that. There are two things I can say to counter it though. The first, is that, with frequent billing, you’ll understand very quickly if your team is becoming wasteful. The moment that 10 hour project hits 12 hours, you can step in and ask why.

The second is that project overruns will happen regardless, the question is where you see the cost. Most companies can only lose so much money. If a piece of software is going to take 40 hours to complete instead of the expected 20, the developer can:

a) Eat the costs

b) Charge for 40 hours

c) Cut costs and make it take 20 hours.

Very few people can afford to take option A. If you’re paying someone a set lump sum, they’re much more likely to take option C because option B isn’t really possible. If you’re paying hourly, you should have the opportunity to choose whether the company chooses to cut costs(i.e quality) or if you just pay more for the product. At that point, you’re given a decision instead of a bad product.


When to go fixed price

Alright, now that I’ve bashed fixed price contracts a bit, there are a few cases where they can be quite useful.

The first is with very small low-risk projects. Cases where you’re paying someone $50.00 for a very simple logo design or to install a pre-built theme for you. These types of projects are very unlikely to extend far in any direction and often have very sharp criteria for success. If you wanted a theme installed and it’s now installed, you’ve achieved success. Setting a predefined value for that success is an easy way to control costs and it tends to be a quick win for the professional who knows what they’re doing.

The second time fixed-cost can be appropriate is with a team you’ve worked with over a long period of time on past projects. In short, when you’re working with people you trust explicitly and you have a strong understanding of the value they bring to the table. If you understand well from past experience what a certain dollar amount can be expected to accomplish, all parties can step to the table in full understanding.

So, what if you really want to do all of your projects fixed price? If fixed price is a requirement for you, I would suggest capturing as much of the value of an hourly contract as possible by insisting on a few things.

1 – Build multiple milestones into the project at a fairly granular level. Let’s go back to our data port example. The data import, in this case, is a well defined piece of the overall website build and can be looked at in isolation and priced as such. If you set a price for that particular piece, payable when it’s complete, you retain the ability to break the project down and avoid situations where you’ve spent half your budget without commensurate results.

2 – Write your contract in a way that gives you full rights after each milestone. If you’ve paid for a theme design, that design is yours regardless of whether the rest of the contract is completed or paid for. Ensure that this is understood. If in doubt, frequently ask for a copy of the project. Most honest professionals who have already been paid will have no problem zipping up the work they’ve done and sending it to you as an archive.


The Mini-Project – Let’s see what you’ve got

One of my favorite propositions is the mini-project. Often, if a client is pursuing a large project($10,000+) I’ll suggest a mini-project to get started. This could be an initial site setup/theme install or something as big as a software prototype, if the product is entirely custom. Either way, the goal is to show the client what they can expect while working within a limited budget on a tangible product. A mini-project is usually between $300-$1,000 and should result in something that adds solid value for the client even if they don’t choose to proceed with the larger project.

At any scale, the mini-project is a good way to test someone’s skill without getting in too deep and should help avoid pitfalls of working with someone who isn’t up to the quality they claim to be.

In parting…

At the end of the day, the two most important components of any professional relationship are trust and communication. If you establish trust with small projects, communicate, and insist on a front row seat to the work that’s being done, you’ll likely have better relationships with your best vendors and will quickly learn to prune those not working in your best interests. Work with someone who will see you as a partner, instead of a sale, and build long term relationships with reliable people. I think you’ll be pleased with the results.

Website Security & PCI Compliance

Much like death and taxes, hackers are one of the certainties of life in the internet world. A single shared server can have dozens of hacked websites on it and a website can easily be hacked multiple times a year if not properly defended. Being small and obscure isn’t necessarily going to save you either. Hackers very seldom target individual sites, at least initially. Your average hacker is going to start with a network scan of a large block of IP’s, sometimes several thousand. After your hacker gets a list of IP addresses that respond, they’ll run a vulnerability scan on those servers.

The vulnerability scan will likely come back with a series of potential hacks, or exploits that could be employed in order to gain access. The important thing to note here is that an attacker doesn’t need to know that your site exists in order to find it on the web, locate a security vulnerability, and exploit that vulnerability.

So how do you stay ahead of the hackers?


The easiest way to keep hackers at bay is also the most mundane. Update everything. Software vendors are constantly releasing updates and patches to help keep you safe but most sites are woefully behind on updates. Updates and upgrades often take a back seat to work that seems to more directly impact the business but they’re the heart of security. Both your web software & your server should be checked for updates and kept up to date regularly.


Web Application Firewalls

You’re probably familiar with the firewall that runs on your computer and it should stand to reason that a firewall is even more critical on servers that are constantly exposed over the internet. A Web Application Firewall is a piece of software or hardware that’s responsible for blocking malicious traffic to your website. A WAF can be a physical piece of hardware you’ve purchased and dropped in a rack or it can be a service, like CloudFlare, that your route your traffic through before it hits your server.


DDOS Protection

DDOS stands for Distributed Denial of Service and it’s a method of attack that relies on overpowering a web server by throwing massive amounts of generic traffic at it. A DDOS is less common than a exploit because it generally requires the attacker to have access to a large pool of machines to initiate the attack from. Unlike an exploit, which generally seeks to access restricted data on your website, a DDOS exists purely for the purpose of taking you off of the web. As a general rule, if you’re being DDOS’d, you’ve either upset someone or you’ve got a hacker testing his abilities on your website. The attacking party has little to gain from this brand of attack.

So how do you stop a DDOS? Your two options tend to be to bulk up, or add enough resources to handle the traffic, or to employ a DDOS prevention service. These tend to be expensive but they’ll filter out the illegitimate traffic before it gets to your site.

Unless you’re running a very large business, employing a DDOS protection service can often be fiscally unfeasible. I would recommend leaving this one alone, unless you happen to be attacked, or trying to find a hosting service that offers one bundled at a discount rate, as many do.


Penetration Tests & Vulnerability Scans

A penetration test, or pen-test for short, involves hiring an Ethical Hacker to attempt to break into your website and show you where it’s vulnerable. Someone running a basic vulnerability scan is also an option and often cheaper. The difference? A vulnerability scan will look for holes in your security, a true pen-test will seek to exploit them.

It’s important, if you’re considering running a pen-test, to speak with your hosting provider prior to the test. If you’re on a shared server, your fake hack attempt could be seen as a real hack attempt on other websites on your server and may constitute illegal action. A good ethical hacker should be able to provide you with information about what is legal and what’s not when it comes to testing a website for vulnerabilities.

PCI Compliance

PCI stands for Payment Card Industry and PCI Compliance is generally a requirement to accept payments on the web. So, how do you find out if your website is PCI compliant?

PCI Compliance is often determined by a PCI compliance scan run by your credit card gateway provider. That could be someone like PayPal or Authorize.net. Normally, while your site is still small, you’re not going to see too many of these. As you start to increase revenue, you’re more likely to start getting messages from your payment provider to become PCI compliant.

The next question that comes up is how we get there. Well, there’s not really one path to PCI Compliance. Every scan is going to turn up different results and different vulnerabilities and standards that need to be met. I can suggest a few loop holes to get around it entirely.

The first is to avoid processing credit cards on your website at all. Using services like PayPal standard and 2Checkout, where a customer is directed to an external website to pay, will completely remove you from the scope of PCI Compliance. If you never actually take a credit card number, you can’t be liable for one.

The second(almost as good) method is to use services like Authorize.net Direct Post. In this scenario, visitors are putting in their credit card number on your website but it’s sent immediately to Authorize.net without ever going through your web server. I won’t get into the technical details of how this works, but it greatly lowers the scope of your PCI requirements.

As a final note on PCI, never, NEVER, store credit card information on your own website. Even though it’s possible to be PCI Compliant while storing local credit card numbers, the risk is simply higher than the reward could ever be. Do you remember what happened to Target recently? Imagine that being your business with hundreds or thousands of customers with credit card numbers filched from your store.E

This post is an excerpt from the short e-book, Understanding Websites from a Business Perspective, available on Amazon.