Magento Imagine 2017

Magento Imagine 2017



We’re gearing up for another year of the Magento Imagine Conference here at InteractOne and are particularly excited to be teaming up with our friends and partners at BluePay. InteractOne and BluePay have joined forces to bring Magento merchants the secure payment processing they need for their stores and customers.

A few features of what BluePay has to offer:

  • Customers want a fast, secure checkout – BluePay delivers in just one step
  • Single-source reporting (one merchant vendor) increases reporting accuracy and efficiency
  • Fully PCI compliant – strongly secures customer data away from your server

Our CEO, Brian Dwyer will be at booth #41. Be sure to stop by and say Hey! If you want to schedule a session with Brian at Imagine, email him at [email protected] or call at (513) 469-3355.

Several other team members are attending including Barb Scales, our Magento Solutions Advocate Extraordinaire. Barb is looking forward to meeting with our clients and talking to Magento merchants about our 100% on-shore development expertise. If you want to schedule a chat or coffee break with Barb, shoot her an email at [email protected] or give her a call at (513) 469-3361.

What we are looking forward to this year at Magento Imagine 2017

There are always excellent speakers and major Magento announcements made at Imagine but, what we look forward to most is meeting with YOU!

A lot of merchants are still wondering how Magento 2 will affect their Magento 1.x sites and their overall business. Are you considering an upgrade to Magento 2? If so, when? Or, are you thinking of moving to a new platform all together? Do you have questions and need answers?  We’re hearing a lot of good questions from the community:

  • We’re running on M1, should we upgrade to M2?
  • What are the differences between Community M2 and Enterprise M2?
  • How do I maintain my SEO rankings with this change?
  • How do I improve conversion with M2?
  • Is M2 more secure for my customers?

If you’re interested in setting up a one-on-one meeting, please email Barb for Magento development at [email protected] or Brian at Barb and Brian are happy to schedule a quick meet up anywhere, a hallway, the pool, how about one of the food and beverage stations? You name it, we’ll be there!

See you at Imagine!

Magento 1 vs. Magento 2

Magento 1 vs. Magento 2


By Brian Holecko Certified Magento Developer at InteractOne

Magento 1 vs. Magento 2 Architecture – What’s the Difference?

After about 10 years from the inception of M1, M2 was released to address many of the shortcomings of M1 using lessons learned from many years of community feedback. Here is a brief list of some of the most critical issues resolved in M2.

  • Extension conflicts

    • Due to a thriving community extensions market, clients tend to rack up on pre-made extensions, with 30 or more community extensions being the norm. The trouble here comes with extension conflicts when two or more extensions try to rewrite the same functionality. This has to be resolved manually and can be very time consuming to determine where the conflict is and how to fix it so that any conflicting extensions are fully functional.
    • Magento 2 introduces plugins which allow code to overlap core code rather than override it. This significantly reduces the chance of conflicting code.
  • Large class files

    • Class files which are most critical to M1 are often large, so large it made it difficult to quickly determine the core functionality of its functions. An architectural decision inherited from less enterprise grade platforms, this eventually became more of a problem as additional functionality was packed on in later releases.
    • M2 solved this issue through dependency injection: abstracting out the dependencies of a class to make it lighter weight and easier to read.
  • Too many JavaScript files

    • M1 made a mistake by choosing Prototype as their core JavaScript library over the more popular jQuery library. This led to most implementations importing jQuery in addition to Prototype, often mixing calls to both libraries which were designed to do the same thing. Also, many extensions require additional JavaScript libraries, resulting in a large number of JavaScript files which were applied to every page of the site, whether in use or not.
    • M2 solved this problem by removing Prototype in favor of jQuery and also adding the RequireJS library. Now, the JavaScript libraries required for any script must be specified beforehand. This change improves performance by reducing the number of JavaScript files which can be called.

Many of the architectural decisions made in Magento 1 were most likely influenced by its predecessor, osCommerce. Magento 2 clearly stands on its own as an independent enterprise platform which is up-to-date with industry trends, both frontend and backend.

Magento has said that support for M1 will end after 3 years from when M2 was initially released. That means that support will likely end sometime around Q4 of 2018. With many features and extensions for M2 created and even free, there’s not a lot of reason to stay on M1. With the end date for support coming up next year,  mixed with the cost of upgrading to M2 vs the cost of maintaining M1, now is the time to make the move.

If you’re currently experiencing issues and conflicts on M1, contact us about moving to M2.

Why We’re Sweet on Magento 2.1

Why We’re Sweet on Magento 2.1

magento 2.1

By Amanda Watkins, Marketing Communications Manager at InteractOne

Magento 2.1 is still pretty sweet, even with its imperfections.

Over the last year, we noticed some casual unrest within the Magento community as we all eagerly awaited to reap the rewards of sticking with the number 1 eCommerce platform in the world. When Magento 2 was released at the end of 2015, there was a lot of excitement and so much to look forward to. We were wide-eyed and hopeful that Magento’s decision to launch Magento 2 (even though we knew it wasn’t totally ready) would be the best thing to happen for us as a development partner and for the community as a whole.

We were enthralled with Magento 2. We held webinars, wrote blogs and built landing pages touting how great it was. We were set. We were ready.

Then 2016 happened.

The first half of 2016 wasn’t easy. In a lot cases, we were talking with clients and prospects advising them to wait to upgrade. We explained that Magento 2 just wasn’t ready due to bugs being worked out and extensions needing built. The first half of the year felt like a stale waiting game. While we waited, we optimized and maintained Magento 1.x sites with the hope that when Magento 2 was ready, we could easily upgrade our clients.

Towards the middle of the year, and with the release of Magento 2.1, we were finally able to start confidently building new sites in Magento 2.  By the end of the year, we were starting to remember those positive feelings we had started 2016 out with. It was coming together and Magento was going to feel great again.

Here’s looking at 2017.

When we read the very real and honest post from our good friend Karen Baker at WebShopApps last month, we felt her frustrations and concerns in every way. The first half of 2016 was frustrating and we hope that Magento is working to make things better. We were also pleased to see that important folks within Magento offered some responses to valid concerns here and here.

We’re continuing into 2017 wiser and more prepared. We know and believe Magento is going to stick around and we’re going to stick with the platform we’ve been with since its inception. There are other tempting eCommerce platforms to watch and definitely keep an eye on, but for now, we’re still sweet on Magento.

As a long time Magento partner, we’re still very excited about Magento 2 and we’re ready to help merchants make the jump. If you want to talk strategy for your next eCommerce move, contact us or give us a call (513) 469-3361.

SUPEE-8788 – Addresses Payment Vulnerabilities

SUPEE-8788 – Addresses Payment Vulnerabilities

SUPEE-8788 – Old Patch – Renewed Urgency!

SUPEE-8788 was released in October of last year but we are still seeing shops without it. We’ve also seen hackers recently continuing to steal data from merchants who have not installed the patch. The two critical fixes address Zend framework and payment vulnerabilities and ensures sessions are invalidated after a user logs out. In addition to the two critical vulnerabilities, there are 15 additional points of concern addressed in the patch.

Vulnerabilities fixed in SUPEE-8788:

  • Remote Code Execution in checkout – With some payment methods, it might be possible to execute malicious PHP code during checkout.
  • SQL injection in Zend Framework – It allows a malicious user to inject SQL through the ordering or grouping parameters.
  • Stored XSS in invitations – It is possible to use the Magento Enterprise Edition invitations feature to insert malicious JavaScript that might be executed in the admin context.
  • Block cache exploit – An attacker with administrator permissions can use static blocks to exfiltrate information stored in cache.
  • Log in as another customer – In certain configurations, it is possible to log in as an existing customer without a password and with only an email address.
  • Remote Code Execution in admin – The import/export functionality in Magento unserializes data supplied from the Admin dashboard without proper checks.
  • Full Page Cache poisoning – It is possible to manipulate the full page cache to store incorrect pages under regular page URL entries. This issue affects only Magento Enterprise Edition.
  • XSS vulnerability in URL processing – Magento function related to URL processing incorrectly uses user-supplied data from request headers. This can result in a cross-site scripting issue.
  • XSS in categories management – It is possible to create a category that contains malicious JavaScript code in the category name. This code will then be executed in other parts of the Admin panel, such as URL rewrites.
  • GIF flooding – A malicious user can upload a modified image that could cause a script timeout.
  • Cross-site scripting in Flash file uploader – Reflected cross-site scripting is possible on sites that use the file custom option.
  • Filter avoidance – Implementing filters for XSS in email templates and other admin features might not be sufficient to stop specially crafted exploit strings.
  • CSRF in several forms – Improper form key validation leads to possible CSRF attacks on several forms throughout Magento.
  • CSRF on removing item from Wishlist or Address Book – It is possible to create a phishing page that would delete the customer’s address or wishlist items.
  • Session does not expire on logout – Session does not expire after logout, making it possible to steal session cookies and access a customer’s account.
  • Lack of certificate validation enables MitM attacks – Lack of certificate validation on calls to external services enables man-in-the-middle attacks on those calls.
  • Timing attack on hash checking – It is theoretically possible to execute a timing attack on the password checking functionality. This is a low-risk vulnerability due to the effort required to execute this attack successfully.

Do you know if your site has the SUPEE-8788 patch installed?

Go to MageReport and check your site for free in a less than a minute, all you need is your URL. When it comes to Magento, security patches should be taken seriously and installed and configured by Magento experts. Contact us today to see if we can get you patched up. 


Give us a call to see how we can get you patched up: (513) 469-3361

Do you know if the patch was installed correctly?

  • This field is for validation purposes and should be left unchanged.
Developing With Large Magento Databases

Developing With Large Magento Databases

large magento databases

By Brian Holecko Certified Magento Developer at InteractOne

A large database can significantly slow down Magento development

When it comes to Magento, one hindrance is developing with a very large DB. This can slow down Magento development considerably making page load speeds grind to a crawl.

With a few techniques, you can reduce page load times and enhance security by removing unneeded data.

First, let’s make sure you are running the system log cleaners on a regular basis in all environments. Under System > Configuration > System > Log > Enable Log Cleaning, make sure this is set to Yes, and Save Log, Days is set to the minimum value required by the client for production systems and about 3 days for development. There is another log cleaner in Enterprise Edition which might be overlooked at System > Configuration > Index Management > Index Clean Schedule > Enable Scheduled Cleanup which should be set to Yes. These settings will prevent some of the most commonly oversized DB tables from filling up too quickly.

Second, make sure you are aware of magerun’s db:dump command. With the @trade and @stripped tags added to the command, you can export a Magento DB with dozens of tables sanitized of their data which will negligibly affect development. Examples include orders, customer, and report data.

Third, you may want to consider a custom shell script to delete large numbers of objects not needed for development. A large product catalog is a common source of slowing down Magento when it comes to page load and reindexing times, however, deleting this data with SQL commands can cause errors and should really be isolated to local development. If you are concerned about truncating tables without adding errors to the system, create a custom shell script to select the objects with a collection and delete them one-by-one. This will ensure only the correct tables are deleted from and will prevent SQL constraints from causing exceptions afterward.

With the above techniques, you should be able to develop without a bottleneck caused by the size of your DB as well as providing enhanced performance to your production environment.

Magento Requirements Analysis

Magento Requirements Analysis

Magento Requirements Analysis
By Brian Holecko Certified Magento Developer at InteractOne

Avoid budget-busters and broken deadlines.

A Magento Requirements analysis will help to avoid one of the most common budget-busters – your team developed the wrong functionality. This will happen when communication is not clear, especially on large projects. In order to reduce miscommunications, you need to track requirements as they emerge in a spreadsheet with both business and technical requirements side-by-side. Business requirements tend to be generalized whereas technical requirements tend to be specific and detailed. Oftentimes, a single business requirement needs to be broken down into multiple technical requirements.

Prior to Magento, I was an enterprise Java developer for highly customized systems. I also attended a certification class which taught this method which is easily transferable to Magento systems and shines brightest when dealing with large requirement sets. Brand new sites need to consider this approach.

A good plan goes a long way.

Create a spreadsheet with the following headers: #, Business Requirement, Technical Requirement, Est. Hours. When capturing a business requirement, put it in plain English so anybody can understand. Then, translate this into one or more technical requirements which allows tech jargon only a developer can understand. The business requirements need to clearly communicate what the client is asking for without referencing technical requirements. By laying this all out, both sides will be able to spot conflicting and/or missing requirements before development starts.

Next, provide estimates at the technical requirements level, summing them into a total estimate at the bottom. Next, add an additional 20% increase in hours for QA to ensure the requirements are delivered accurately since not all requirements can be captured down to the fine details.

If the list of business requirements is long, add an additional column to categorize the requirements by a system attribute like usability, scalability, UX, etc. There should not be no more than 3-5 of these attributes/categories and need to be defined before defining any requirements. This guides the discussion around the attributes/categories most desirable and will result in an attribute-driven approach to designing and developing the site.

The above method will prevent your team from breaking budgets and missing deadlines on large projects as well as providing an attribute-driven architecture of the store.

Magento Coding Standards

Magento Coding Standards


By Brian Holecko Certified Magento Developer at InteractOne

Abide by the Magento Code

Magento coding standards for Magento 1.x exist to aid in proper modifications to the system. Although these standards may seem overbearing, they are a reflection of the sensitivity and scope of the complex websites we work on. As a developer, if you are not going to follow these standards it’s a good idea to obtain client approval.


  • Core modifications
    • Code residing in app/code/core/ is intended to remain intact exactly as they were coded to allow for easy upgrades. It is possible to override this functionality by copying the files to app/code/local/, however, this should be done only in rare cases where a custom extension cannot override the core. A common example is modifying the translator function within app/code/core/Mage/Core/functions.php for WordPress integration.
    • A common mistake is to create a php file in the web root and include Mage.php which is problematic because it bypasses important core features.
    • It should also be noted to keep the web root free of extraneous files which can be accessed via public URL since they might contain sensitive data (DB dumps for example).
    • Be sure to keep all files in the distribution intact which are beneficial but might be missed during project installations and migrations. A common example is var/.htaccess which prevents these files from being publicly accessible.
  • Default theme files
    • Use a custom directory in either the default, enterprise, or rwd directories for theme modifications.
    • Do not copy layout XML files into custom theme directories. Any modifications to these files can be made using a custom layout XML file.
    • Use a custom CSS file for style modifications unless styles.css is going to be heavily modified.
  • Shell scripts
    • Make sure shell scripts extend Mage_Shell_Abstract and reside in the shell directory.
  • Custom code
    • If confused about how to solve a problem, consider using the core for example solutions.
Has your Magento 1 Site Morphed Into a Frankenapp?

Has your Magento 1 Site Morphed Into a Frankenapp?

magento frankenapps

Got a Magento Frankenapp on your hands?

Starting to feel like your M1 site has turned into a Magento Frankenapp that’s difficult to control? We’ve seen Magento Frankenapps appear out of the darkness over the years. Core hacks, patched up code, rickety extensions here, duck tape there. These (usually unintentional) Frankenapps are products of inexpensive labor, DIY fixes, inexperienced developers, patches and shall we go on? Unfortunately, updates and fixes for Magento 1.x will be gone forever and you’ll be left with your Frankenapp.

Not to worry, there’s a way to clean up your code and get your Magento site back on track!

Magento 2 is an opportunity to clear the slate and rebuild your site for success.  With Magento 2 you get a completely new code base and database that comes ready for scalability and is mobile friendly right out of the box.  All of your data (customers, orders, catalog and CMS) from Magento 1 can easily be transferred to Magento 2 via the data bridge connector.  That means you now have the chance to go back to the foundation and start fresh by building the great new scalable site you always wanted but without the overhead of migrating to a different platform.

With many of the kinks and issues fixed in Magento 2.1 and with more than a 100 Magento 2 extensions available, there’s never been a better time to make the move.

Highlights of Magento 2.1 updates:

  • Content staging and preview – create, preview and schedule new content
  • Improved management interface  –  faster and easier to search for info in the admin
  • Payment information updates – PayPal enhancements and Braintree updates
  • Elasticsearch – handles large catalogs and can scale as search volume grows
  • Security enhancements – known vulnerabilities have been updated

As we build more and more projects in Magento 2, we’re helping put those Frankenapps to bed.

Contact InteractOne to learn more about moving your Monster to Magento 2.

PHP v5.5 to v5.6 Could Affect your Magento Installation

PHP v5.5 to v5.6 Could Affect your Magento Installation

By Greg Reedy, PHP/MySQL Developer at InteractOne

What you need to know about upgrading PHP v5.5 to v5.6

If you’re a Magento merchant or developer, you’re well aware that the platform is well into its new life as Magento 2, however, you may not be aware that it is also well underway into a new life of patches and upgrades. Magento 2.0 was released in Q4 2015, and now – at the time of this writing – has iterated from version 2.0.0 all the way up to 2.1.1. That’s eleven minor version upgrades!  Now, is that something new or abnormal? Nope. This happens all the time with software, but sometimes updates occur within these minor upgrades that can affect things immensely, so it’s important to keep on top of what has changed and how it could affect your Magento store’s online environment.

Magento is, of course, built on PHP, and in an effort to stay up-to-date with technology, the requirements to run Magento have updated as well.

In the initial minimum requirements published with the M2 release, PHP versions 5.5.22 to 7.1.0 were acceptable.

from the original Magento 2 Developer Documentation


  • 5.6.x
  • 5.5.x, where x is 22 or greater
  • 7.0.2 up to 7.1.0, except for 7.0.5

However, upon the release of Magento 2.1, support for PHP 5.5 ended.

from updated M2 Developer Documentation

System requirements

Our technology stack is built on PHP and MySQL. Magento 2.1.0 supports:

  • PHP 5.6 We do not support PHP 5.5x
  • PHP 7.0.2, 7.0.6 up to 7.1
  • MySQL 5.6
  • Apache 2.2 or 2.4
  • nginx 1.8(or latest mainline version)

Why does this matter?

It matters because your hosting company is likely about to automatically upgrade PHP on all of their servers to 5.6 from 5.5, and your M1 installation may not be ready for it! One day you wake up, your site is down, and clearing those Magento caches has zero effect.

All you see is something like this in the error log:

ERR (3): Deprecated functionality: iconv_set_encoding(): Use of iconv.internal_encoding is deprecated  in lib/Zend/Locale/Format.php on line 311

Why is this happening?

Because PHP 5.5 has come to an “end of life” (EOL) and nobody invited you to the funeral!2016-09-30_1142

So long PHP 5.5!


How do I fix it?

To keep your sturdy M1 site humming right along, there are a few simple fixes to get it to play nicely with PHP 5.6:

Fix #1: Upgrade to the latest version!

Magento’s latest releases of M1 have made the backwards compatibility to handle the deprecated functions. You can simply upgrade to the latest versions of Community Edition ( or Enterprise Edition ( and the deprecated functionality shouldn’t be an issue.

Fix #2: Patch the offending files in the Zend

The main issues really fall in the Zend library that ships with M1. If upgrading isn’t immediately possible (let’s inject here that official upgrades and updates are always recommended), a mediary solution can be to simply patch the offending files in the Zend folder by copying them to your local codepool and modifying the necessary lines.

Copy from:


Copy to:


Edit the newly copied files by searching for “internal_encoding” and replacing it with “default_charset”. Be sure that the “internal_encoding” string is a parameter of an iconv related function, otherwise it will break the code. (EXAMPLE: Don’t replace any other parameters or variable names by accident, such as “mb_internal_encoding” or “$internal_encoding” or any other unrelated elements, or you may otherwise certainly break your code.

In the official releases of the latest versions, the files listed above have defined constants to compare the PHP version against and they set the encoding accordingly.



However, setting the encoding in the above listed files to a fixed value should be fine as long as the PHP version is 5.6 or above.



With the actively occurring PHP upgrades happening now among hosting companies across the internet, it’s imperative to make sure your online store is up-to-date and ready. Many hosting companies will upgrade their servers without warning which could cause major outages and downtime. It is often up to merchants to be pro-active and ensure their stores remain open for business in the event of an unanticipated update such as this (which is no longer in the distant future!).

Contact InteractOne today and have our Magento team review your site’s integrity and viability for growth!

Optimizing Page-Specific CSS/JS for Magento

Optimizing Page-Specific CSS/JS for Magento

Programmer Edited3

By Brian Holecko Certified Magento Developer at InteractOne

The One Technique to Further Boost Magento Performance

There are many techniques available for optimizing page-specific CSS/JS which are well documented throughout the Magento ecosystem, however, there is one technique to further boost performance which should be more commonly noted. This technique is only beneficial when using merged CSS/JS, which should be used in all production environments, however, lack of awareness regarding this technique might prevent the use of merged CSS/JS all together due to an innate downside.

Magento’s default theme includes some CSS/JS files on a limited set of pages rather than the entire site. Notably, customized themes commonly include this type of file. When page-specific CSS/JS is available, the merge process combines it with site-wide CSS/JS into its own bundle, forcing the site-wide CSS/JS to be re-downloaded. By leveraging Magento’s available capabilities, these page-specific files can easily be separated from site-wide files. This prevents them from being re-downloaded and improves average page load times for the site. Which overall, maintains a more consistent user experience. By setting a parameter named “page” on the addition of CSS/JS in the layout XML, these files will be separated and bundled independently when merged.

Here is an example setting:

Optimizing Page-Specific CSS/JS

Here is an example result:

Optimizing Page-Specific CSS/JS


Developers should analyze the layout XML and use the page parameter on the addition of CSS/JS files outside of the default and print layout handles which are considered common CSS/JS.

Contact us if you need help optimizing your Magento code.