Four Tips for Preserving Magento’s Core Code

Four Tips for Preserving Magento’s Core Code

Magento’s Core CodeBy 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

Patch or Upgrade Magento?

Patch or Upgrade Magento?

patch or upgrade Magento
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.

Magento Imagine 2017

Magento Imagine 2017

nevada-932708_640

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!

Magento 1 vs. Magento 2

Magento 1 vs. Magento 2

sunburstbackground

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

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.