By Brian Holecko Certified Magento Developer at InteractOne

Preserving Magento’s Core Integrity

Magento’s Core Code is intended to be preserved – not modified – so that upgrades can be completed gracefully and without error. The common procedures for extending the core using observers, overriding functions for blocks, helpers, models, and controllers are often leveraged appropriately.

However, there are a handful of techniques for the front-end that are worthy of discussion and exploration. Often, these are not used owing to controversy over what is actually included in Magento’s core code and what is not.

Here are four important front-end tips for preserving Magento’s core code.

styles.css and other base CSS files
In regard to the skin, styles.css and other base CSS files should be treated like core files. A separate CSS file (local.css or custom.css) should be used to override styles, even if there are many changes to be made to the default styles.

Theme base files
Theme base files should be treated similar to core files in regards to layout files. Too often, layout files are copied over to a custom theme directory for minor edits. These edits should instead be put into a single layout file named local.xml or custom.xml. Any edits made to the layout files after being copied over can be achieved using a custom layout file including removing CSS/JS references and other functions which may not be necessarily obvious how to code.

Template files
Template files sometimes have hooks to add additional content, so instead of copying over a template file, try to create a new block in the layout if possible. Also, it is  best-practice to defer to using CSS to correct templates instead of changing the HTML.

/js/ directory
The /js/ directory should be treated as core as well. Modifying these files are discouraged, however, if it is required, be sure to place them into the skin JS directory instead of the core directory.

With these four tips in mind, you will have a cleaner theme with reduced amounts of core edits.  Your site will be easier to upgrade when necessary and will be closer to standard Magento development best practices.

Concerned that your core code may have been compromised? Contact us to learn more about our Code Review and Maintenance and Support options or call us 513-469-3361

By Brian Holecko Certified Magento Developer at InteractOne

The Security Patch Conundrum

Patch or upgrade Magento? When it comes to your Magento site, it is less of a question of philosophy, and more a question of security. Magento promotes security patches through admin notifications. These notifications can alarm merchants, causing them to request urgent patching of their online store. Do not be alarmed, security patches are far more numerous than indicated via the admin notification system. It is actually “best practice” to upgrade to the latest Magento version which often includes dozens of security fixes, including the latest security patches. If a security patch is released before its inclusion in an upgrade, be patient and focus on staying up-to-date on upgrades instead.

What if you get hacked?

One very important reason to stay up-to-date on Magento is what if your site is hacked? There is no simple way to easily tell which security hole was breached. Best case scenario, it’s a hole that an existing security patch can fix. Or worst case, it could be an issue that won’t be patched for a long time to come in older versions of Magento.

When new weak points are discovered in Magento and even if they’re urgent, patch requests take time. They have to pass through project management, development, and QA testing before being released to production. This is critical time in which your site can be exploited. Even if you patch the security breach, a hacker still may resort to another weak point, potentially leading your development team into a game of whack-a-mole with the hacker.

Security Patches violate a key Magento rule – never edit core code. 

The implementation of security patches violates a Magento standard which says that modifications should not be made directly to the core code, which patches do. This can cause confusion during a code analysis when determining whether core edits to the code have been made by a developer or not. Future upgrades will overwrite the patches which have been applied, providing little gain for having applied the patch over upgrading.

Ok, so do I Patch or Upgrade Magento? Upgrade!

To get the most protection, it is best to stay up-to-date on the latest upgrade. With an upgrade, you get the protection of multiple security fixes via upgrading, rather than get the protection of only one security patch at a time. It is recommended that you meet with your team to develop an upgrade plan which will define the time and effort to upgrade, as well as a test plan and of course, budgetary constraints to determine when and how to upgrade to the latest version and when not to upgrade.

VIVA LAS VEGAS!

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 bdwyer@interactone.com. 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!

By Brian Holecko Certified Magento Developer at InteractOne

Magento 1 vs. Magento 2

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. Some of the most critical architectural issues resolved in M2 involve extension conflicts, large class files, and JavaScript files. In addition, there are many upgrades to the admin and front end to improve customer experience. 

Architectural Differences in Magento 2

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.

New Key B2B Features in Magento 2

• Account management – You are able to manage accounts, create sub-accounts, and set permissions and roles easily.
• Negotiated Pricing Terms – You can associate accounts with specific price lists, payment options, and shipping methods.
• Mobile Responsive Design – your customers will be able to order on any device or platform.
• Quick Order – Your B2B customers will be able to create a quick and easy re-order, large scale orders, and even recurring orders.
• Credit Accounts – You can customize for the businesses to make purchases based on their needs. They can check out now and pay later.
• Inventory Tracking – You will be able to manage your inventory across multiple warehouse locations.

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 the patch was installed correctly?

[gravityform id=”14″ title=”false” description=”false”]

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.