When we talk about Shopify performance, most discussions focus on Lighthouse scores, image optimisation or JavaScript bundles.

Relatively few people take the time to understand what actually happens when a customer visits a Shopify page.

Every product page, collection page and landing page goes through a complex request lifecycle involving DNS resolution, CDN delivery, server-side Liquid rendering, browser processing and asset loading before the customer sees a fully interactive storefront.

For architects, developers and technical leaders, understanding this journey can help explain where performance bottlenecks originate, why certain optimisation techniques work, and where effort should be focused.

The High-Level Journey

At a simplified level, a Shopify page request follows this flow:

While this appears straight forward, a simple request has at least 13 layers to through; each stage contains multiple layers of processing.

Stage 1: DNS Resolution

Everything starts when a customer enters a URL or clicks a link.

Before Shopify can serve any content, the browser must determine where the website lives.

The browser performs:

• DNS lookup
• Connection establishment
• TLS negotiation
• HTTP/2 or HTTP/3 connection setup

Shopify’s platform documentation notes that storefront traffic is delivered through Shopify’s global CDN infrastructure, backed by Cloudflare, and uses modern protocols including HTTP/3 and TLS 1.3 to improve both performance and security. See more here: https://shopify.dev/docs/storefronts/themes/best-practices/performance/platform

This process typically completes in milliseconds, but geographical location, network quality and DNS configuration all influence the result, and downtime with Cloudflare means downtime for your site.

Stage 2: Request Reaches Shopify’s Edge

Once the connection is established, the request reaches Shopify’s edge infrastructure. The edge layer acts as the first point of contact for every storefront request and provides:

• Traffic routing
• Distributed delivery
• Cache management
• Compression
• Security controls
• DDoS protection

Shopify serves assets through its CDN using same-origin URLs under the store’s own domain. This avoids additional DNS lookups and connection overhead that can occur when assets are hosted separately.

For static assets such as:

• Images
• CSS
• JavaScript
• Fonts

The CDN may be able to serve content immediately without further processing. Dynamic storefront pages however require additional work.

Stage 3: Storefront Renderer Takes Over

For dynamic content, Shopify’s Storefront Renderer (SFR) processes the request.

Shopify describes Storefront Renderer as a dedicated server-side rendering system responsible for handling storefront requests as quickly as possible. This is where Shopify begins constructing the page.

The renderer must determine:

• Which page has been requested.
• Which template should be used.
• Which store data is required.
• Which sections and snippets need rendering.

Unlike client-heavy frameworks, most Shopify storefronts still generate their core HTML on the server.

This means customers receive a fully rendered document rather than a blank page waiting for JavaScript execution.

Stage 4: URL Routing

The renderer analyses the requested URL and identifies the associated resource.

For example:

/products/leather-wallet

becomes:

/products/leather-wallet

while:

/collections/new-arrivals

becomes:

Collection Resource

Similarly:

/pages/about-us

/blogs/news

/search

/cart

all map to different resource types.

This routing process determines which data models and templates Shopify will use next.

Stage 5: Template Selection

Once Shopify knows the resource being requested, it identifies the appropriate template.

Modern Online Store 2.0 themes primarily use JSON templates.

Shopify’s architecture documentation explains that templates define which sections should appear on a page, while layouts provide the broader page structure around them. Eg;

product.json

may contain:

• Product Section
• Product Recommendations
• Recently Viewed Products
• FAQ Section

All configured in a merchant-editable structure. This flexibility is one of the major enhancements introduced by Online Store 2.0.

Stage 6: Data Loading

With the template selected, Shopify loads the necessary objects.

Depending on the page, this may include:

Product Pages

• Product data.
• Variants.
• Images.
• Metafields.
• Inventory availability.

Collection Pages

• Collection information.
• Product listings.
• Filters.
• Sort orders.

Global Objects

• Shop settings.
• Theme settings.
• Customer details.
• Locale information.
• Market configuration.

Shopify loads these objects before Liquid rendering begins. The amount of data requested here can have a direct impact on performance. Stores with large numbers of metafields, excessive looping, or overly complex rendering logic often experience increased server-side render times.

Stage 7: Liquid Rendering

This is where the magic happens.

Liquid is Shopify’s server-side templating language.

The rendering engine combines the following into a complete HTML document.:

• Templates.
• Sections.
• Blocks.
• Snippets.
• Shopify data objects.

Shopify’s theme architecture consists of the following which all participate in generating the final page.:

• Layouts.
• Templates.
• Section Groups.
• Sections.
• Blocks.
• Snippets.

For example:

{% render 'product-card', product: product %}

renders reusable snippet content into the page. Shopify’s render tag is specifically designed to generate snippets safely and consistently during server-side rendering.

At this stage the customer still hasn’t received any HTML.

Everything is happening inside Shopify’s infrastructure.

Stage 8: HTML Response Sent to Browser

After rendering completes, Shopify returns the generated HTML.

This response contains:

• Fully rendered markup.
• CSS references.
• JavaScript references.
• Image URLs.
• Metadata.
• Structured data.
• Analytics integrations / 3rd Party Scripts.

The faster Shopify can complete rendering, the lower the Time To First Byte (TTFB).

This is why inefficient Liquid logic can become a performance issue. Liquid executes before the HTML reaches the browser, meaning poor server-side implementation increases wait time for every visitor.

Stage 9: Browser Parsing Begins

Once HTML arrives, the browser begins creating:

The DOM

A representation of the page structure.

The CSSOM

A representation of all styling rules.

The browser then starts assembling the Render Tree. At this point the page may begin appearing on screen before all assets have completed loading. This perceived performance is often more important than total page load time.

Stage 10: Asset Requests

The browser discovers additional resources and requests them.

Common examples include:

• CSS files.
• JavaScript bundles.
• Fonts.
• Product imagery.
• Videos.
• Third-party tags.

Most of these assets are delivered directly from Shopify’s CDN.

For imagery specifically, Shopify can dynamically:

• Resize images.
• Convert image formats.
• Compress assets.
• Deliver AVIF/WebP where supported.

This is one reason properly implemented Shopify themes can achieve excellent image performance.

Stage 11: JavaScript Execution

After downloading JavaScript assets, the browser begins execution.

This is often where performance challenges emerge.

Common offenders include:

• Search integrations.
• Review applications.
• Personalisation engines.
• Loyalty platforms.
• Analytics tools.
• Tag managers.

Many organisations spend significant effort optimising images while overlooking the impact of dozens of third-party scripts running simultaneously.

In practice, excessive JavaScript is often a larger source of performance degradation than Shopify itself.

Stage 12: Hydration and Customer Interaction

Modern Shopify themes now contain far more interactive components than traditional ecommerce platforms.

Examples include:

• Predictive search.
• Variant selection.
• Media galleries.
• Dynamic carts.
• Recommendation engines.

Once JavaScript completes execution, these elements become interactive.

The page is now considered fully usable.

Why This Matters

Understanding the Shopify page request lifecycle helps teams identify where performance problems actually originate.

A slow page could be caused by:

The key takeaway is that Shopify performance is rarely determined by a single factor.

A customer experiences the combined effect of:

• Network latency
• Platform performance
• Theme architecture
• Asset optimisation
• Third-party dependencies
• Browser execution

Conclusion

A Shopify page request is far more than a simple webpage download. Between the initial DNS lookup and the final interactive storefront, the request passes through Shopify’s global CDN, Storefront Renderer, theme architecture, Liquid rendering engine and browser rendering pipeline.

For technical teams, understanding this lifecycle provides a framework for diagnosing performance issues and making better architectural decisions. Whether you’re optimising Core Web Vitals, reducing TTFB, auditing app performance or redesigning a theme architecture, the most successful improvements come from understanding where time is actually being spent during the request journey.

Put simply: before you can optimise a Shopify storefront, you need to understand how Shopify builds it.

The post What Happens During a Shopify Page Request? appeared first on Independent technical advice for ecommerce projects based in Yorkshire.

Today, that separation is rapidly disappearing.

Modern ecommerce retailers are increasingly transforming their PDPs into powerful merchandising environments packed with product recommendations, outfit inspiration, bundles, upsell opportunities, and related products. Rather than acting as the end point of the buying journey, PDPs are becoming destinations in their own right, encouraging continued browsing and product discovery.

Fashion retailer Next provides an excellent example of this shift. Visit a typical product page and you’ll often find substantial sections dedicated to coordinating items, similar products, recommended purchases, and alternative styles. In some cases, these merchandising components occupy more space than the product’s core information itself.

This evolution represents one of the most significant changes in ecommerce merchandising over the past decade.

The Traditional Role of the PDP

Historically, the purpose of a PDP was straightforward: convert interest into a sale.

Product pages typically contained:

• Product images
• Descriptions and specifications
• Pricing information
• Variant selection
• Delivery and returns details
• Add to basket functionality
• Reviews

Any product recommendations were generally treated as secondary content. A “Customers Also Bought” carousel might appear at the bottom of the page, but it played a supporting role to the primary objective of helping customers evaluate a specific product.

The underlying assumption was that product discovery had already happened elsewhere.

Customers discovered products on:

• Category pages
• Search results
• Promotional landing pages
• Homepages

By the time they reached a PDP, the retailer’s job was simply to remove friction from the purchase decision.

That assumption no longer reflects how customers actually shop.

The Modern Customer Journey Is Far Less Linear

One of the biggest drivers behind this trend is the changing nature of customer acquisition.

Increasingly, visitors arrive directly on product pages rather than entering through category structures.

Customers may land on a PDP from:

• Google Shopping results
• Organic search
• Social media platforms
• Influencer content
• Email campaigns
• Affiliate links
• AI-powered search experiences & LLMS

In many cases, the PDP is the first page a customer sees.

This creates a challenge for retailers. If a visitor enters the site halfway through the traditional journey, how do you expose them to the wider product catalogue?

The answer is simple: bring the discovery experience to the PDP.

Rather than forcing customers back to category pages, retailers now surface relevant products directly alongside the item they’re currently viewing.

The Rise of the PDP as a Merchandising Hub

The best modern product pages no longer focus solely on selling a single item. Instead, they attempt to maximise the commercial value of every site visit.

This has fundamentally changed how merchandising teams think about PDP design.

Using retailers such as Next as an example, a typical product page may now include:

Complete the Look

Particularly common in fashion retail, these modules present complementary products chosen to create a full outfit.

Instead of purchasing a shirt, customers are encouraged to buy:

• Trousers
• Shoes
• Jackets
• Accessories

The retailer is no longer selling a product. They’re selling a solution.

Similar Products

Many PDPs now include substantial grids of comparable items.

These may feature:

• Alternative colours
• Different fits
• Similar styles
• Alternative brands
• Different price points

Functionally, this mirrors the role traditionally performed by a category page.

Frequently Bought Together

Cross-selling modules encourage customers to purchase related items alongside their primary purchase.

For example:

• Trainers with cleaning kits
• Laptops with accessories
• Furniture with matching products

These recommendations are designed specifically to increase basket value.

Recently Viewed Products

This allows customers to continue product exploration without needing to return to a PLP.

The result is a browsing experience that feels more fluid and less constrained by traditional site architecture.

Why Retailers Are Investing So Heavily in PDP Merchandising

The answer comes down to economics.

Customer acquisition costs continue to rise across virtually every digital marketing channel.

Retailers are spending significant sums on:

• Paid search
• Paid social
• Influencer partnerships
• Display advertising
• Affiliate networks

When attracting visitors becomes more expensive, increasing revenue per visitor becomes a strategic priority.

As a result, retailers are placing much greater emphasis on metrics such as:

• Average Order Value (AOV)
• Revenue per Session
• Units per Transaction
• Basket Size

Every PDP view becomes an opportunity not just to secure a purchase, but to increase the overall value of that purchase.

The mindset shifts from:

“How do we sell this product?”

to:

“How do we maximise the value of this customer session?”

Technology Is Enabling Smarter Recommendations

The growth of personalisation technologies and recommendation engines has accelerated this trend dramatically.

Historically, related products were often manually curated by merchandising teams.

Today, recommendation engines can analyse the following to determine which products should appear in recommendation zones:

• Customer behaviour
• Purchase history
• Browsing patterns
• Category affinities
• Product relationships
• Profit margins
• Inventory availability

This creates a much more dynamic experience.

Two customers viewing the same product may see entirely different recommendations based on their behaviour, interests, or previous purchases.

As AI-powered personalisation continues to mature, PDPs are becoming increasingly individualised rather than serving as static templates.

The Benefits for Customers

Although the trend is commercially motivated, it isn’t solely beneficial for retailers.

When implemented well, customers also gain a better shopping experience.

Faster Discovery

Customers can explore alternative products without repeatedly navigating back through category structures.

Better Inspiration

Fashion retailers can showcase complete looks rather than individual products, helping shoppers visualise how items work together.

Reduced Effort

Relevant recommendations remove the need for customers to perform multiple searches to find complementary products.

Improved Mobile Experiences

On mobile devices, moving between category pages and product pages can feel cumbersome.

Integrated discovery modules create a smoother browsing experience that requires fewer taps and screen transitions.

The Risks of Over-Merchandising

Despite the benefits, there is a danger that some retailers may take the concept too far.

The more recommendation modules added to a PDP, the greater the risk of distracting customers from the primary conversion goal.

Potential issues include:

• Decision paralysis
• Cognitive overload
• Reduced focus on the featured product
• Longer purchase journeys
• Lower page performance

Many retailers are also introducing additional JavaScript and third-party recommendation services, which can negatively impact Core Web Vitals and overall site speed.

A poorly optimised PDP can feel less like a curated shopping experience and more like an endless stream of competing recommendations.

The challenge is finding the right balance.

The Future of Ecommerce Product Pages

The distinction between Product Listing Pages and Product Detail Pages is becoming increasingly blurred.

As acquisition costs rise and personalisation technologies improve, ecommerce retailers are transforming PDPs into sophisticated discovery and merchandising environments that extend far beyond their traditional purpose.

The most successful retailers will be those that strike the right balance between helping customers make a purchasing decision and encouraging further exploration of the catalogue.

Rather than viewing PLPs and PDPs as separate stages of the customer journey, brands are beginning to treat them as complementary experiences that can fulfil many of the same objectives.

In many ways, the modern PDP has become a highly focused, highly personalised Product Listing Page.

The future of ecommerce is unlikely to be defined by a strict separation between browsing and buying. Instead, it will be characterised by pages that seamlessly combine both, helping customers discover more products while simultaneously moving them closer to conversion. The PDP is no longer the final stop on the journey. Increasingly, it’s where the journey truly begins.

The post PDPs Are Becoming the New PLPs: Why Product Pages Are Taking Over Product Discovery appeared first on Independent technical advice for ecommerce projects based in Yorkshire.

For luxury and premium brands in particular, an ecommerce site has to feel as considered as the product itself. Design commentary across luxury ecommerce regularly highlights high-quality photography, elegant visual hierarchy, minimalist layouts, strong storytelling and seamless user journeys as defining characteristics of premium digital experiences. Sites in this space often use large hero imagery, full-screen video or photography-led landing pages, refined typography and spacious layouts to create a sense of exclusivity and emotional connection.

Image-heavy stores introduce a performance challenge: every visual asset has a cost. Large unoptimised images increase page weight, slow down Largest Contentful Paint, delay perceived load time and can negatively affect conversion, mobile experience and search performance.

Shopify provides a strong foundation through its CDN and image transformation capabilities, but clients still need to prepare, size and manage assets carefully before upload.

Why Image Optimisation Matters on Shopify

Images are often among the heaviest assets on ecommerce pages, especially on product detail pages, collection pages, campaign landing pages and homepage hero sections. Shopify’s own theme performance guidance states that performance directly influences conversion rates, repeat business and search engine rankings. Shopify also advises theme developers to build with performance in mind, with image loading, JavaScript usage and rendering behaviour all contributing to storefront speed.

For image-led brands, the goal is not to reduce visual quality to the point where the experience feels compromised. The goal is to deliver the right image, at the right dimensions, in the right format, at the right time.

A luxury homepage still needs rich photography, but a mobile visitor should not be forced to download a 6000px desktop campaign image, as the rendered viewport only needs a much smaller version.

Good Shopify image optimisation improves:

• Page speed — smaller and better-sized images download faster.
• Largest Contentful Paint — hero images are often the LCP element.
• Mobile experience — smaller assets matter more on constrained networks.
• SEO — performance and well-written alt text both support discoverability.
• Conversion — faster browsing reduces friction in product discovery.
• Operational consistency — agreed upload standards reduce ad hoc performance issues over time.

How Shopify’s CDN Delivers Image Content

Shopify includes a global content delivery network for storefront assets. Its CDN is designed to host, transform, compress and deliver image files quickly from distributed edge infrastructure. Shopify describes its CDN as supporting file compression, file format conversion and dynamic editing, including real-time transformations such as resizing and cropping without destructively changing the original uploaded asset.

When an image is uploaded to Shopify, the original file is stored and can then be requested in different transformed variants.

Theme code can use Shopify’s Liquid image filters, particularly image_url, to request a specific width, height, crop or other transformation. You can find a list of attributes that you can use within Liquid to do this; https://shopify.dev/docs/api/liquid/filters/image_url

Shopify can also serve modern image formats where supported. Shopifyautomatically detects supported client-side file formats and can deliver WebP or AVIF where supported, with JPG as a fallback for other clients. This means the browser’s capabilities can influence the final file delivered, helping reduce transfer size without merchants having to manually create every format variant.

A simplified request flow looks like this:

In practical Shopify theme development, this matters because the theme should not simply output the original uploaded file everywhere. Instead, it should request appropriately sized variants. For example:

{{ product.featured_image | image_url: width: 800 }}

This asks Shopify’s CDN for an 800px-wide version of the image. Shopify’s image_url documentation confirms that if only width is specified, the height is automatically calculated based on the image’s dimensions.

For responsive images, developers can combine Shopify’s image filters with srcset and sizes, allowing the browser to select the most appropriate image for the user’s viewport and device pixel ratio. Shopify has long recommended responsive image approaches as a way to reduce page loading times, particularly because mobile visitors do not need to download desktop-sized images.

<img
  srcset="
    {% if image.width >= 350 %}{{ image | image_url: width: 350 }} 350w,{% endif %}
    {% if image.width >= 750 %}{{ image | image_url: width: 750 }} 750w,{% endif %}
    {% if image.width >= 1100 %}{{ image | image_url: width: 1100 }} 1100w,{% endif %}
    {% if image.width >= 1500 %}{{ image | image_url: width: 1500 }} 1500w,{% endif %}
    {{ image | image_url }} {{ image.width }}w
  "
  src="{{ image | image_url: width: 1100 }}"
  loading="eager"
  fetchpriority="high"
  width="{{ image.width }}"
  height="{{ image.height }}"
  alt="{{ image.alt | escape }}"
>

What Shopify Optimises Automatically — and What It Does Not

Shopify gives merchants a good baseline, but it is not a complete substitute for good asset preparation.

Shopify can help with:

• CDN delivery from distributed infrastructure.
• Automatic compression to reduce file size without visible quality loss in most cases.
• Dynamic resizing and cropping using URL/Liquid parameters.
• Modern format delivery, including WebP or AVIF where the client supports it.
• Preservation of the original file, so that transformations are non-destructive.

However, clients and implementation teams still need to manage:

• The size and quality of the original uploaded asset.
• Whether the theme requests sensible image dimensions.
• Whether above-the-fold images are prioritised correctly.
• Whether below-the-fold images are lazy loaded.
• Whether product images follow consistent aspect ratios.
• Whether decorative imagery is being overused.
• Whether app-injected images bypass the intended theme logic.
• Whether alt text and filenames are meaningful.

Shopify can optimise delivery, but it cannot fully compensate for poor source assets or poor theme implementation.

Image Optimisations Clients Should Complete Before Uploading to Shopify

1. Resize images to a sensible maximum dimension

Clients should avoid uploading enormous camera-original files unless there is a specific need for zoom-level detail. If an image will never be displayed above 2000px wide, uploading a 6000px file creates unnecessary storage and processing overhead.

As a practical rule:

• Product images: usually export between 1600px and 2400px wide, depending on zoom requirements.
• Collection tiles: often 800px to 1600px wide is sufficient.
• Homepage hero images: typically 2000px to 3000px wide for desktop, with separate mobile crops where possible.
• Logos and icons: use SVG where appropriate, rather than raster images.

Shopify’s image_url filter supports generated widths up to 5760px, but images cannot be enlarged beyond their original dimensions. That means clients should upload large enough files for legitimate use cases, but not unnecessarily huge originals.

2. Use the right file format

Choose the source format based on image type:

• JPEG/JPG — best for photography, lifestyle imagery and product shots without transparency.
• PNG — best for transparency, sharp UI graphics or cases where lossless quality is required.
• SVG — best for logos, icons and simple vector graphics.
• WebP — useful for already-optimised web-ready assets, though Shopify can also deliver modern formats through its CDN where supported.

For most photographic ecommerce imagery, a well-compressed JPEG source is still a sensible and widely compatible upload format, with Shopify then handling transformed delivery to modern formats where appropriate.

3. Compress images before upload

Clients should export images using tools that balance quality and file size. The objective is not maximum compression; it is visually lossless compression. A product image should retain texture, colour and detail, but should not contain unnecessary metadata or excessive quality settings.

Suggested export targets:

• Product listing thumbnails: ideally under 100–200KB where possible.
• Product detail images: often 200–400KB, depending on complexity.
• Hero banners: ideally under 400–700KB, with careful treatment for mobile.

These are not hard limits, particularly for luxury or detail-led brands, but they are useful targets.

4. Create separate crops for mobile and desktop

A common mistake is to use a single wide desktop hero image for all devices. On mobile, this can result in either poor cropping or excessive asset size.

Clients should provide:

• A desktop crop, usually landscape.
• A mobile crop, often portrait or square.
• A clearly defined focal point.
• Safe zones for overlaid text, calls to action and navigation.

This is especially important for luxury campaign imagery, where the subject, model, product or composition may be carefully art-directed.

5. Standardise product image aspect ratios

Inconsistent product image ratios can create layout shifts, uneven grids and awkward cropping. Clients should agree image rules before content population begins.

For example:

• Fashion model photography: 4:5 or 3:4.
• Product packshots: 1:1 or 4:5.
• Lifestyle banners: 16:9 or 21:9.
• Editorial tiles: controlled set of ratios, not arbitrary uploads.

Consistent image ratios help the theme reserve layout space and avoid visual instability.

6. Remove unnecessary metadata

Camera metadata, location data, colour profiles and editing history can increase file size. Before uploading, clients should strip unnecessary metadata while preserving the correct colour profile for web display.

7. Write useful filenames and alt text

Image optimisation is not only about compression. Filenames and alt text support accessibility, SEO and content management.

Instead of:

IMG_9023-final-final-v4.jpg

Use:

black-leather-crossbody-bag-front.jpg

Alt text should describe the image clearly and naturally, particularly for product images. Shopify’s image object includes an alt property, and Shopify recommends using image_url and image_tag filters to display images in storefront themes.

8. Avoid uploading text-heavy images

Text embedded inside images is difficult to localise, poor for accessibility and can become blurry on small screens. Where possible, campaign text should be rendered as HTML over the image, not baked into the image itself.

This gives the implementation team more control over:

• Responsive typography.
• Accessibility.
• Translation.
• SEO.
• A/B testing.
• Mobile layout.

9. Check colour and quality after compression

Compression should be reviewed visually before upload, especially for luxury brands where material detail, colour accuracy and finish matter. Leather grain, jewellery reflections, fabric texture and cosmetics shades can all be affected by aggressive compression.

Clients should compare:

• Original export.
• Compressed version.
• Mobile preview.
• Product zoom state.
• Dark and light background contexts.

Implementation Recommendations for Shopify Teams

Although this article focuses on client-side image preparation, the Shopify implementation also needs to be correct.

Development teams should:

• Use image_url instead of hardcoded original image URLs.
• Specify explicit width or height parameters, because Shopify requires one of these for image_url.
• Use responsive srcset and sizes.
• Lazy load below-the-fold images.
• Avoid lazy loading the main above-the-fold hero/LCP image.
• Reserve image dimensions to reduce layout shift.
• Audit third-party apps that inject unoptimised media.
• Test templates with Lighthouse, WebPageTest and real device throttling.

Shopify’s performance best-practice documentation makes it clear that performance is central to merchant success and influences conversion, repeat business and search visibility. Image handling should therefore be treated as part of the technical delivery strategy, not as an afterthought during content entry.

Final Thoughts

Image-heavy brand experiences are now a core part of premium ecommerce. For Shopify merchants, this creates a balancing act: the store must feel rich, immersive and visually distinctive, but it must also remain fast, responsive and usable across devices.

Shopify’s CDN provides a strong technical foundation through global delivery, automatic compression, dynamic transformations and modern format support. Its Liquid image tooling allows development teams to request appropriately sized image variants rather than serving oversized originals. But the best results come when clients, designers, content teams and developers all follow a joined-up image strategy.

Make sure you upload high-quality but sensible source assets, let Shopify’s CDN do its job, and ensure the theme requests the right image for the right context.

The post Luxury Without Lag: How to Optimise Images on Shopify for Speed and Impact appeared first on Independent technical advice for ecommerce projects based in Yorkshire.

OPEN SOURCE

The post Magento Support Deadlines appeared first on Independent technical advice for ecommerce projects based in Yorkshire.

The probability of selling to a new prospect is 5-20%. The probability of selling to an existing customer is 60-70%.

So, what tools are at our disposal?

Upselling, and cross-selling are important tools that introduce customers to bigger, better and complementary products that you offer.

Offline retailers have been doing this for a very long time – the main drive for a sales team is to sell the customer a more expensive item, or sell them more items.

So, what is the difference between upselling and cross-selling?

When I started researching this post, it became apparent that cross-sell, upsell and related products are all used interchangably by both consumers and by online stores. I surveyed the office (now around 70 people) and found that this caused some confusion. So, let’s define them and find some good examples to show their worth.

Upselling

I think that Dell is a great example for showing upselling working well online.

Their configuration tool is a constant up-selling model. Dell “starts” you on a base model, and then allows you to customise from there, immediately.

This style of customisation is upselling in practise. Why have this model, when you can have one better, or one we recommend more highly? Dell are trying to essentially get you to spend more money on the item you’re looking to purchase.

As soon as you add an item to your cart, Dell also shows you what you get by default, and then tries to offer you something better.

As you can see from the screenshot, you’re already signed up for 1 year enhanced support. Why not get 2, 3 or 4 years?

Upselling often brings higher gains, and in turn, higher customer retention for certain products.

Cross selling

Once you’ve bought your new shiny computer – and you’ve picked a better processor – what are you going to need to go with it? This is where cross selling comes in.

Do you need a mouse? A monitor? A headset? A printer?

All of these are logical cross sells when purchasing a computer. Things you might need.

Amazon is a great example of this.

However, usually, you’d want to be offering a specific product.

So, is Upselling and Cross-Selling Important?

Upselling and cross selling can boost revenue by selling more to your customer. It’s important to note that this interaction improves your customer’s experience too. If they’re buying a new TV, you can make sure they’re buying the right one for them, and it’s also important to offer them the items that will let them get the most out of their new product.

Which is more effective?

According to a report from PredictiveIntent in 2012, upselling leads to around a 4% increase in conversion, whereas cross selling only raised around 0.2%.

The research however did state that it was aggregated across all their clients, and individual clients had increases in conversion of around 3% when cross selling was displayed in certain key areas – such as the checkout process.

It’s an important balance for an e-commerce store to ensure that a customer ultimately reaches the “checkout” phase as quickly as possible and completes a purchase; weighed against offering the customer – who is in a buying mindset – the ability to purchase more from you.

Cross selling

With the majority of ecommerce platforms, it’s a lot easier to get data based on what sells, rather than looking more indepth into what users visited initially, and what they ended up buying. If categorisation is good, you can probably get a fairly good read on this, but it will require more indepth profiling, and you’ll need to give up product page real estate to promote other products. Whilst this makes sense for the likes of Dell, for non-specialised businesses it makes less sense.

Ultimately, you’d like your customer to spend more money with you, but how you go about this has the potential to be too direct and jarring for the customer experience on your site.

There are a number of factors to increase conversions of you cross sells. A major attribute is value. Try not to offer the customer items that are over 20% the price of the product they’re looking at.

Customers are much more likely to purchase lower-priced add-ons to their purchase than additional big ticket items. This obviously helps if the main item is already expensive. The same goes for upsell items – you don’t want to try and upsell to an item that costs a lot more than the original.

Where to use Upsells and Cross sells

So, you have an ecommerce store, where should you position your upsells and cross sells?

Upsells

Upsells really need to be on a product page.

Apple show a very good example of this across their iPhone and iMac pages:

You’ll probably see a more regular example from Amazon, or from Interflora.

Cross Sells

You’ll often also see cross sells on product pages, but also on pre-basket pages, and on basket pages themselves.

Tesco show cross sells on the basket page, but they could be doing so much more here – like selling me bags for the vacuum cleaner I’ve added.

Finding the balance

Remember, there is a fine line between interupting the checkout journey and empowering a customer to make an additional purchase.

The post How to improve customer experience, and increase revenue by using cross selling effectively in ecommerce appeared first on Independent technical advice for ecommerce projects based in Yorkshire.

Caching

Most likely, your development and even staging versions of your site don’t have caching turned on. Turn it on; if nothing else, you at least need your config caching activated.

Google page speed

Use the Google page insights tool. It’s probably worth going over this while you’re still on your staging site but obviously, some page speed issues are likely to be improved by your live server infrastructure. Make sure you check over your live site as soon as possible. Since 21st April 2015, Google have been more vigilant with websites’ mobile-friendliness. Use the Google mobile friendly test in order to ensure that your Magento store is ready.

301 redirects

If you already have a site – whether or not it’s on Magento, you’re going to need a firm 301 redirection plan. Google is clever, but why not make it as easy as possible for them? Provide it with a list of pages that you’ve moved from one place to another. Be as specific as possible and avoid double hops as much as can be helped. This might mean that you want to implement them at server level instead of rewrites within Magento where possible through something like Apache or Nginx. Redirect maps were built for this; if you have a large number of redirects, use them.

Update base URL

If you’ve been working on a staging site, or you’re replacing an existing site from your development version, make sure you update the base URL.

Maintenance.flag

If you’re making changes to a site, this file is your friend. If you create this file (it doesn’t need any content) – then Magento will go into maintenance mode. It’s especially useful if you’ve got a lot of files to upload over FTP and you’re not deploying via GIT. Create the file and then deploy.

Switching payment methods from staging/test to live – and test your checkout!

A lot of things stop customers buying from your site. The most important step to get right is when a customer is all the way through your funnel and they’re trying to put in their payment details, and something doesn’t work. It’s not just going to call into question how reliable your site is, but also how secure your site is. Additionally, you don’t want customers checking out with a test integration and expecting you to ship your items!

Contact details and transactional emails

The most important things for your customer before and after purchasing goods from your store are a) being able to contact you and b) knowing that they’ve made a purchase from a reputable company.

Make sure you have contact details on your site. Magento makes this easy – find them in System -> Configuration -> General, System -> Configuration -> Store Email Addresses, and System -> Configuration -> General -> Store Information. Obviously, your template needs to show these details on the front end of the site – make sure you update them!

Transactional emails use a different logo to your main site. Ensure you have a “logo_email.gif” image in your theme folder if you haven’t already customised your email templates. When thinking about Magento, the sales order email is probably the only one that you can guarantee someone who purchases from your site. Make sure you test it – and that you’re happy with it. Make sure it’s packed full of information about the order and that you also take this opportunity to engage your customer as much as possible – highlighting promotions or upselling items, for example. Finally, ensure you test your emails with a testing system, like Emailonacid.

Newsletter subscription emails

Turn them off if you haven’t styled them. By default, they’re a one-line plain text email and you don’t want to spam your customers, do you? It’s best to check whether you can subscribe and unsubscribe at the same time – you don’t want your customers testing this for you.

Placeholder images

You should have already ensured that all images have been uploaded for products in your store. You should be able to quickly run through the admin products grid to see that images have been uploaded, but creating a small script to double-check could be a good idea.

If you’ve missed any products, Magento has got your back. Placeholder images: where can you manage these? If you’re a developer, you could just create catalog/products/placeholder/small_image.jpg, catalog/products/placeholder/thumbnail.jpg and catalog/products/placeholder/image.jpg. If you want to help your merchant, you’re probably just going to want to take the easy option. Upload them in the admin system: System -> Configuration -> Catalog -> Catalog -> Product Image Placeholders. Here, you can set them for specific store views too.

Test your orders, customers and products

Don’t develop blindly; test everything. If you’re looking to make sure your site is ready for release, you’ll have added customer accounts, test orders and should have a large amount of products. Quite often, you might not have the finalised versions of any of these three.

To this end, make sure that you clear your database of all the test items you have before you go live. You don’t want to have to be trawling through lists of test orders with skewed reporting figures. You also don’t want to be sending automated emails to your test users or your customers buying test products. Furthermore, you don’t want Google crawling those products and listing them for the world to see.

Your 404 page

Make sure you have your 404 page customised for your store. Whilst the default 404 gives a nice “standard” interface, don’t go live with the default 404 page. It’s often overlooked and should be tailored to the experience your customers expect from your site. Be sure that as well as being in the correct design format, it provides relevant links to your customer journey and supports your site and brand.

Log cleaning

Another thing that you don’t worry too much about in development or staging environments are your logs. However, once live, this could bring your entire site down if said logs get too large. Make sure you’re checking them in development to make sure that you catch anything that is likely to cause you issues when you go live. Once live, ensure you set up log rotation so that you don’t have to sift through logs in order to find the item that is causing you a problem. System -> Configuration -> Advanced -> System -> Log Cleaning is your friend. This is disabled by default, meaning your database can essentially grow continuously. For high traffic stores, you might even want to disable the logging module entirely.

SSL certificate

If you’re making use of an SSL certificate, make sure it is in place. If possible, purchase a certificate for your staging environment so that you can test and make sure that all assets are available over a secure connection when required. Configure Magento to use this as the secure base URL as well. Some payment providers won’t allow you to go live until an SSL certificate is in place either.

Module licenses

Many modules require live and staging license keys. Make sure that you switch out the staging version for the live version when you go live. Otherwise, you might not have any shipping options, or perhaps your customers won’t be able to enter their card details! Make sure the keys are valid for your live domain when you make the switch.

The post Magento – A go-live checklist appeared first on Independent technical advice for ecommerce projects based in Yorkshire.

Here, we’ll have a look at a script that will remove all images from a product, and then add some new ones that we’ve got ready. We’re working on the assumption here that the client has had a number of new shots done for all products, so we’ll be running through all products in the system. We’re going to also assume that there is one image per product to be added and that it is named the same as the SKU of the product.

Removing product images

Firstly, we’ll grab all products in the system.

$collection = Mage::getModel('catalog/product')->getCollection();

If you have a lot of products in your store, you might want to filter this, so you’re only dealing with a limited, and managable product range.

To remove images from a product, the easiest way is via the Product Attribute Media API Model. So, we’re going to grab that model now.

$mediaApi = Mage::getModel("catalog/product_attribute_media_api");

This model has a remove method which takes two variables as input. The product id, and the file you’re trying to remove (as remember, a product might have multiple images). We’re removing all images in our example, so we’re going to retrieve all images for the product and then loop through them removing each one, one at a time. If we wanted to only remove a particular image, or image tagged specifically (eg. the base image, swatch small images or thumbnail), then we could check within this loop.

$items = $mediaApi->items($product->entity_id);

$items will be an array of media attached to the product – meaning we can iterate through it and get each item. $item['file'] will be the filename of the asset, so we can call the catalog/product_attribute_media_api model’s remove method.

Here’s the code in full.

error_reporting(E_ALL);
ini_set('memory_limit', '1024M');
require_once '../app/Mage.php';

umask(0);
Mage::app()->setCurrentStore(Mage_Core_Model_App::ADMIN_STORE_ID);

// load all products
$collection = Mage::getModel('catalog/product')->getCollection();

$mediaApi = Mage::getModel("catalog/product_attribute_media_api");

foreach ($collection as $product) {
    echo $product->entity_id;

    try {
        $items = $mediaApi->items($product->entity_id);
	foreach($items as $item) {
	    if($mediaApi->remove($product->entity_id, $item['file'])){
                echo " image removed";
            } else {
                echo $item['file'] . " image not removed";
            }
	}
    } catch (Exception $exception){
        echo $exception->getMessage();
        die();
    }

    echo "\n";

}

I’ve added a quick bit of debugging in so that we can see line-by-line, product-by-product if the code is passing or failing. If you’d like to live in a world of make-believe and wonder, simply comment out or remove the “echo” statements.

Adding Images

Now that we’ve removed all the images, we’re going to add some new ones.

Preparing image files

Magento needs the images to be in a specific folder in order to import media into the system when you’re using dataflow or product import services within the admin system – namely /media/import/ When adding images programmatically, you don’t need to do this, but I’m going to follow best practice in my example and make other developer’s lives easier rather than having random folders of images laying around – so, I’m going to store them in here anyway.

Importing the images

As mentioned previously, we’re going to make some assumptions in our script:

– All new images to import is in /media/import/new-product-images-2014/
– There is only a single image per product
– The image has the same name as the SKU of the product
– The image should be set as the main image, small image & thumbnail for the product

Given the above information, there is actually only one key bit of information we need to add the product image into Magento. Once we have a $product object, we can call the addImageToMediaGallery() method on it to add an image from a path on the filesystem.

The addImageToMediaGallery() method takes 4 attributes.

• $file – The file path of the image in the filesystem
• $mediaAttribute – Array of where the image should appear
• $move – Should the image be moved (if true) or copied
• $exclude – Mark the image as disabled in the product page view

$_productImage = "media/import/new-product-images-2014/mysku.jpg"; // our reference to the new image
$_product->addImageToMediaGallery($_productImage, array( 'image', 'small_image', 'thumbnail' ), false, false);

The post Image management for Magento1 appeared first on Independent technical advice for ecommerce projects based in Yorkshire.

Interceptors are how Magento 2’s object system implements the plugin system.

In theory, you don’t need to worry about how Magento provides the underlying plugin system in order to use it.

When you ask Magento for an object, it may return an interceptor, or it might return your referenced class.

How it’s implemented

If a class has a plugin configured, the object manager will return an interceptor.

Magento handles the delivery of an interceptor different ways depending on how your environment is configured.

Production Mode

In production mode, Magento will look through your solution during compilation, and create interceptors for plugins where required.

Magento handles plugin creation with a separate PHP autoloader. If a developer triggers a PHP autoload event, and the composer based autoloader can’t find the class file, a second registered autoloader is called:

Magento\Framework\Code\Generator\Autoloader

/**
 * Load specified class name and generate it if necessary
 *
 * @param string $className
 * @return bool True if class was loaded
 */
public function load($className)
{
    if (!class_exists($className)) {
        return Generator::GENERATION_ERROR != $this->_generator->generateClass($className);
    }
    return true;
}

So, what’s happening here?

Magento is making a call to Magento\Framework\Code\Generator::generateClass.

/**
 * Generate Class
 *
 * @param string $className
 * @return string | void
 * @throws \RuntimeException
 * @throws \InvalidArgumentException
 */
public function generateClass($className)
{
    $resultEntityType = null;
    $sourceClassName = null;
    foreach ($this->_generatedEntities as $entityType => $generatorClass) {
        $entitySuffix = ucfirst($entityType);
        // If $className string ends with $entitySuffix substring
        if (strrpos($className, $entitySuffix) === strlen($className) - strlen($entitySuffix)) {
            $resultEntityType = $entityType;
            $sourceClassName = rtrim(
                substr($className, 0, -1 * strlen($entitySuffix)),
                '\\'
            );
            break;
        }
    }

    if ($skipReason = $this->shouldSkipGeneration($resultEntityType, $sourceClassName, $className)) {
        return $skipReason;
    }

    $generatorClass = $this->_generatedEntities[$resultEntityType];
    /** @var EntityAbstract $generator */
    $generator = $this->createGeneratorInstance($generatorClass, $sourceClassName, $className);
    if ($generator !== null) {
        $this->tryToLoadSourceClass($className, $generator);
        if (!($file = $generator->generate())) {
            $errors = $generator->getErrors();
            throw new \RuntimeException(implode(' ', $errors));
        }
        if (!$this->definedClasses->isClassLoadableFromMemory($className)) {
            $this->_ioObject->includeFile($file);
        }
        return self::GENERATION_SUCCESS;
    }
}

As you can see from the code above, after name matching, it checks to see if there is any reason that the generation should be skipped.

Let’s take a look at an example.

We’re going to take a look at vendor/magento/module-customer/Model/Plugin/AllowedCountries.php. As you can see, we have a before method called on getAllowedCountries.

namespace Magento\Customer\Model\Plugin;

use Magento\Customer\Model\Config\Share;
use Magento\Store\Api\Data\WebsiteInterface;
use Magento\Store\Model\ScopeInterface;
use Magento\Store\Model\StoreManagerInterface;

/**
 * Class AllowedCountries
 */
class AllowedCountries
{
    /**
     * @var \Magento\Customer\Model\Config\Share
     */
    private $shareConfig;

    /**
     * @var StoreManagerInterface
     */
    private $storeManager;

    /**
     * @param Share $share
     * @param StoreManagerInterface $storeManager
     */
    public function __construct(
        Share $share,
        StoreManagerInterface $storeManager
    ) {
        $this->shareConfig = $share;
        $this->storeManager = $storeManager;
    }

    /**
     * Retrieve all allowed countries or specific by scope depends on customer share setting
     *
     * @param \Magento\Directory\Model\AllowedCountries $subject
     * @param string | null $filter
     * @param string $scope
     * @return array
     * @SuppressWarnings(PHPMD.UnusedFormalParameter)
     */
    public function beforeGetAllowedCountries(
        \Magento\Directory\Model\AllowedCountries $subject,
        $scope = ScopeInterface::SCOPE_WEBSITE,
        $scopeCode = null
    ) {
        if ($this->shareConfig->isGlobalScope()) {
            //Check if we have shared accounts - than merge all website allowed countries
            $scopeCode = array_map(function (WebsiteInterface $website) {
                return $website->getId();
            }, $this->storeManager->getWebsites());
            $scope = ScopeInterface::SCOPE_WEBSITES;
        }

        return [$scope, $scopeCode];
    }
}

Magento creates an interceptor, thus:

namespace Magento\Directory\Model\AllowedCountries;

/**
 * Interceptor class for @see \Magento\Directory\Model\AllowedCountries
 */
class Interceptor extends \Magento\Directory\Model\AllowedCountries implements \Magento\Framework\Interception\InterceptorInterface
{
    use \Magento\Framework\Interception\Interceptor;

    public function __construct(\Magento\Framework\App\Config\ScopeConfigInterface $scopeConfig, \Magento\Store\Model\StoreManagerInterface $storeManager)
    {
        $this->___init();
        parent::__construct($scopeConfig, $storeManager);
    }

    /**
     * {@inheritdoc}
     */
    public function getAllowedCountries($scope = 'website', $scopeCode = null)
    {
        $pluginInfo = $this->pluginList->getNext($this->subjectType, 'getAllowedCountries');
        if (!$pluginInfo) {
            return parent::getAllowedCountries($scope, $scopeCode);
        } else {
            return $this->___callPlugins('getAllowedCountries', func_get_args(), $pluginInfo);
        }
    }

Magento is extending the original class to allow our additional code to run. It returns the Interceptor class rather than the original.

This explains a few of the limitations listed in the previous article, such as why you cannot use a Plugin on a class with a final method, or on static method calls.

Developer Mode

In developer mode, where everything is done on the fly, the following code is run:

public function getInstanceType($instanceName)
{
    $type = parent::getInstanceType($instanceName);
    if ($this->interceptionConfig && $this->interceptionConfig->hasPlugins($instanceName)
        && $this->interceptableValidator->validate($instanceName)
    ) {
        return $type . '\\Interceptor';
    }
    return $type;
}

From vendor/magento/framework/Interception/ObjectManager/Config/Developer.php

Magento internally uses the vendor/magento/framework/Interception/ObjectManager/InterceptableValidator class in order to validate an interceptor.

The post How Magento2 implements Plugins appeared first on Independent technical advice for ecommerce projects based in Yorkshire.

Aspect Oriented Programming (AOP) is a programming paradigm that tries to increase modularity of code. It does this by allowing the separation of “cross-cutting” concerns.

This means that the code is streamlined to do exactly what it needs to do, without having to worry about code that operates to undertake processing throughout the rest of the application.

An example

Let’s have a look at a quick example. This example focuses on the need to log within an application.

public function doSomething()
{
    try {
        //do something
        $this->logger->debug("something");
    } catch (\Exception $e) {
        $this->logger->critical($e);
    }
}

As you can see from the example, we have a large amount of code that is taking care of logging, and logging any exceptions, but the main code is relatively small. If we wanted to swap out our logging pattern, it could be quite a large undertaking, as you can imagine that this kind of code would be littered everywhere within our application.

Wouldn’t it be much nicer, if our code just did what it needed to do.

public function doSomething()
{
    //do something
}

How does AOP work?

AOP tries to overcome this by adding additional behaviour to our existing code – an “advice” – without modifying the code itself. Instead, it specifies which code is modified via a “point cut” specification.

AOP allows developers to apply these “advice” to crosscutting concerns – logic applicable throughout the application, that affects the entire application – such as logging in our example above. Security and data transfer are also concerns which are needed in almost every module of an application.

A segway into SOLID

Let’s have a quick segway into SOLID principles. These are five core principles of object oriented programming and design. The concept behind these principles is that it will allow for greater maintainable code that can be extended over time.

The principles are:

• Single responsibility
• Open-closed
• Liskov substitution
• Interface segregation
• Dependency inversion

What we’re looking at is the Single responsibility. We want the code to take care of it’s concerns/responsibilities only. Classes and methods should only have one responsibility, and do one thing.

AOP allows us to satisfy this requirement. Our core classes and methods do the task that we expect, and the cross cutting concerns are taken care of within code that interacts with our existing code.

Plugins in Magento2

Magento2’s implementation of AOP is done in the form of Plugins – you may also see these referred to as interceptors in Magento documentation.

Plugins allow a developer to “Listen” to any public method call made on an object manager controlled object and take programmatic action. It allows for the behaviour of the method to be modified and have code run before, after, or around the method call.

This means you could extend, or even substitute an existing method.

Additionally, you can change the return value of any method call made on an object manager controlled object, change the arguments of any method call made to an object manager controlled object, all whilst other plugins are doing the same thing to the same method in a predictable way.

Magento implements this using the interceptor pattern (why you might see these referred to as interceptors).

As mentioned in the wikipedia article referenced above, one of the key aspects of the interceptor pattern is that the rest of the system does not have to know something has been added or changed and can keep working as before.

Limitations to the implementation

Magento’s implementation means that you cannot use AOP with any of the following:

• Objects that are instantiated before Magento\Framework\Interception is bootstrapped
• Final methods
• Final classes
• Any class that contains at least one final public method
• Non-public methods
• Class methods (such as static methods)
• __construct
• Virtual types

Our AOP options

Before: Executes before a join point, but which does not have the ability to prevent execution flow proceeding to the join point (unless it throws an exception).

In Magento2, we use the method prefix before and simply camel case the method name.

After: Executed after a join point completes normally: for example, if a method returns without throwing an exception.

In Magento2, we use the method prefix after and simply camel case the method name.

Around: Surrounds a join point such as a method invocation.

Around can perform custom behaviour before and after the method invocation. It is also responsible for choosing whether to proceed to the join point or to shortcut the advised method execution by returning its own return value or throwing an exception.

In Magento2, we use the method prefix around and simply camel case the method name.

Defining Plugins in Magento2

Magento2 allows developers to create plugins using standard PHP classes, and reference them using XML within di.xml.

There are a series of Required options:

• Type name: The name of a class or interface that needs to be followed.
• Plugin name: The name for the new plugin in Magento 2. This is arbitrary and is simply used during mergin XML to give your plugin a unique reference.
• Plugin type: The name of a plugin’s class or its virtual type. \Vendor\Module\Plugin\ModelName\Plugin.

There are additionally couple of optional options:

• Plugin sortOrder: Set the order in which the plugin should be called.
• Plugin disabled: That allows you enable or disable a plugin quickly. As the default configuration, the chosen value is false. This allows you to write a global di.xml and then override (and disable) a Plugin in an area specific di.xml such as frontend / adminhtml.

Some examples from core

Before

Here we have an example from \Magento\Theme\Model\Theme\Plugin\Registration.

Note the keyword before in front of the method we want to intercept dispatch.

/**
 * Add new theme from filesystem and update existing
 *
 * @param AbstractAction $subject
 * @param RequestInterface $request
 *
 * @return void
 * @SuppressWarnings(PHPMD.UnusedFormalParameter)
 */
public function beforeDispatch(
    AbstractAction $subject,
    RequestInterface $request
) {
    try {
        if ($this->appState->getMode() != AppState::MODE_PRODUCTION) {
            $this->themeRegistration->register();
            $this->updateThemeData();
        }
    } catch (LocalizedException $e) {
        $this->logger->critical($e);
    }
}

It’s achieved with the following entry in di.xml specifically in the adminhtml scope.

After

This function specifically invalidates the indexer registry when an item is deleted.

/**
 * Invalidate design config grid indexer on store removal
 *
 * @param StoreStore $subject
 * @param StoreStore $result
 * @return StoreStore
 *
 * @SuppressWarnings(PHPMD.UnusedFormalParameter)
 */
public function afterDelete(StoreStore $subject, $result)
{
    $this->indexerRegistry->get(Config::DESIGN_CONFIG_GRID_INDEXER_ID)->invalidate();
    return $result;
}

It’s achieved with the following entry in di.xml.

Around

Here we have an example from \Magento\Theme\Model\Url\Plugin\Signature.

This functionality ensures that any call to getBaseUrl() returns a string that ends with a forward slash. Note the keyword around in front of the method we want to intercept getBaseUrl.

/**
 * Append signature to rendered base URL for static view files
 *
 * @param \Magento\Framework\Url\ScopeInterface $subject
 * @param callable $proceed
 * @param string $type
 * @param null $secure
 * @return string
 * @see \Magento\Framework\Url\ScopeInterface::getBaseUrl()
 *
 * @SuppressWarnings(PHPMD.UnusedFormalParameter)
 */
public function aroundGetBaseUrl(
    \Magento\Framework\Url\ScopeInterface $subject,
    \Closure $proceed,
    $type = \Magento\Framework\UrlInterface::URL_TYPE_LINK,
    $secure = null
) {
    $baseUrl = $proceed($type, $secure);
    if ($type == \Magento\Framework\UrlInterface::URL_TYPE_STATIC && $this->isUrlSignatureEnabled()) {
        $baseUrl .= $this->renderUrlSignature() . '/';
    }
    return $baseUrl;
}

It’s achieved with the following entry in di.xml

Using around

You’ll notice in the method above that there is a call to $proceed, a PHP closure that allows the method to call the method it is intercepting. With great power, comes great responsibility. It is the around method’s responsibility to call the callable. If it doesn’t, it prevents the execution of all the plugins that follow it.

When you use around on a method that accepts arguments, your plugin method must also accept those arguments – and you must forward them when you invoke the proceed callable. You must match the original signature of the method, including default parameters and type hints – otherwise, your plugin may introduce unintended exceptions.

If you’re doing nothing with these arguments, you can use variadics and argument unpacking to achieve this.

This doesn’t seem to be used in CORE at the moment, but allows you to do the following:

    public function aroundSave(\X\Y\Model\Z $subject, callable $proceed, ...$args)

Prioritisation

I’d suggest checking out the dev docs for more details on prioritisation, as they’re got some great examples: Prioritizing plugins.

The post Aspect Oriented Programming (AOP) – Plugins with Magento2 appeared first on Independent technical advice for ecommerce projects based in Yorkshire.

For anyone not in the know, MageTitans is an extremely successful Magento conference organised by Manchester Digital & Space48 for the last two years – with additional events around the world.

MageTitans is an event for Magento Developers, curated by Magento developers.

I don’t want to go too in-depth breaking down each talk – as I’m sure others will, and the videos will be available soon, but I did want to highlight some of the key concepts and talking points from the conference presentations.

• All Magento2 online training resources will be free in the months of December and January
• In the future, there will be longer pre-notification of patches for both Magento 1 and Magento 2
• Frontend framework for Magento 2 is moving toward BEM & SASS
• Use the “best practise” tag on Stack Exchange to find (and explain) best practise for Magento 2
• Don’t use the Object Manager in Magento 2 directly!
• Avoid Gold-Plating your new extensions – Support a version of Magento 2, and avoid spending hundreds of hours supporting older versions of Magento 2 – people will upgrade
• No one actually knows what OOP is – thanks to Vinai for filling us in!
• Alan Kay got a lot of mentions – the father of OOP
• We can all learn from functional programming even if we’re not using it
• Monitor everything you can about your application
• Agree on metrics with your client, and measure performance
• Don’t make decisions on (not) caching within your community extension. Allow store owners to take control.
• There is a great New Relic dashboard for looking at FPC hits/misses – https://maxchadwick.xyz/blog/monitoring-magento-fpc-hit-rate
• The devdocs now advise against using $isScopePrivate
• Always think about FPC at the beginning of every project. Could toward it
• Skip creating sessions for bots, crawlers and anything else that doesn’t need them with https://github.com/AOEpeople/Aoe_BlackHoleSession
• Magento will never be cutting-edge on the frontend, but it doesn’t need to be. There is a pay-off for having reliability.
• Mini cart, basket and dashboard are good core examples for AJAX calls for private data
• There is still a long way to go before Magento2 can support Subresource Integrity
• JS has been radically overhauled in Magento 2. Magento 1 had 386 JS files, Magento 2 has over 12k
• Magento 2.1.3 has optimised rendering flow for tabs – hidden tabs are initialised, but not rendered
• Always start your AWS EC2 instances in auto scaling groups
• Get involved with Meet Magento World
• Don’t forget to rate the speakers – https://joind.in/event/mage-titans-mcr/schedule/list

The post MageTitansMCR 2016 appeared first on Independent technical advice for ecommerce projects based in Yorkshire.

Whilst most of that was me trying to remember why I’d even thought getting on stage was a good idea, I wanted to get down some thoughts in a post to share.

For the best part, I don’t have to remind people how great the Magento community is. You’re probably already part of it if you’re reading this. This great community comes together at events like Mage Titans, and other events, all across the globe. However, these events are spread out over a large geographical area, and unless you have a very rich boss or you’re Ben Marks, chances are you might get to visit one every 6 months.

This is where a local user group can play a key role.

As Cal Evans was once quoted: “Community Works! If I have a question, someone has the answer. If I have a problem, someone has the solution. If I just need to vent, there’s always someone out there willing to be my rubber duck.”

Usergroups are fantastic places to meet like minded people. What’s better than Stack Exchange? Stack Exchange in real life.

Rewind a year, and I worked for a company on the outskirts of Leeds. Leeds is a big digital hub, and there were a large number of events to pick and choose from. LeedsPHP, https://twitter.com/leedsjs and WPLeeds to name only a few.

Whilst I worked in Leeds, I live in York; and whilst it’s not too much of a trek to Leeds, there are very few user groups here – and I was still missing the one important thing I was looking for – a Magento User Group.

When I moved jobs to York, my manager and I decided that it was about time to do something. So we set up MagentoYork. It does exactly what it says on the tin. It’s a Magento user group, for people based in / around York, and we meet in York once every two months or so.

Once we had a venue sorted (a pub), we needed to find people to talk with.

We set up a group on Meetup.com, and I fired off a few emails and submitted the odd contact form to local companies that I knew produced Magento sites.

Luckily, our first meeting had more attendees than just myself and my team. Not many more mind, but, once we met and talked, we all had a better understanding of who we were, why we were there, and what we thought we could get out of the group.

With the meetings in Leeds, I was a nomad, only surfacing for the odd meeting, and really not getting behind them and being at one with them. However, my attendance did make me think about what I wanted from other user groups – and ultimately what I wanted out of MagentoYork.

So what kind of things can you expect to get out of a user group?

• Talks. Usually the backbone of a “structured” usergroup. In the case of MagentoYork, we try to keep technical and marketing angles covered to give variety for developers and merchants. Essentially, all developers are merchants to some degree – and all merchants are developers.
• Discussion. Discussing approaches broadens your problem solving skills. We’re a very open group. There’s no right and wrong a lot of the time.
• Wider topic discussion. Magento is a huge topic to cover, but add to that running a department, running a company, finding business, discussing your favourite editor, your preferences for deployment and development – there is a huge range of topics that can be discussed.
• Feeling part of something bigger. Giving back and helping the Magento community that supplies so much knowledge and power – all mostly free of charge.
• Speaking experience for those so inclined. Usually to a lovely bunch of folk who, over a short number of meetings, can become friends

I would strongly encourage you to find a user group in your area for something you are passionate about. Can’t find one? Create one! Unless you’re into something very niche, there will be likeminded people out there.

It’s important that once you’ve found a user group, you contribute. That might just be turning up to each meeting, or it might be speaking, organising or promoting it to others.

The post Setting up a Magento Users Group – Why finding like-minded people is so important appeared first on Independent technical advice for ecommerce projects based in Yorkshire.

The beauty of Docker, is that we have the speed of the host system for accessing our source code (no more mounted drives), but also, the flexibility of running our stack and swapping out any components we need – don’t want to use Apache anymore? Switch out the container for Nginx, back up and running in minutes.

So, over the Christmas period, I started exploring Docker on Mac, and then, in January, started exploring Docker on Windows.

Access Windows mounted directories directly from within a Docker container

You cannot mount a windows directory from directly within your container, due to the DockerMachine (running as a VM). Whilst you can mount a volume using something like docker run -it -v /docker-data:/data debian bash you can only do this if the /docker-data is within your Users folder – Kitematic will tell you this if you try and add a directory .

So, what if you want to outside of your Users folder? It’s a little more complicated.

Firstly, you’re going to want to close down your Docker VM. Simply open up VirtualBox, find the VM called Default and shut it down.

Navigate to your VirtualBox folder in a command prompt – cd "C:\Program Files\Oracle\VirtualBox"

Next, run the VirtualBox Media Manager and add a new folder to your VM.

VBoxManage sharedfolder add default --name --hostpath "" so, something like: VBoxManage sharedfolder add default --name mydata --hostpath "d:\development\"

mydata is going to be the name of our data folder. So you’ll be able to use whatever name you want here.

Now, start your VM.

Next, you should SSH into your Docker VM. Open up a Docker Terminalm and ssh docker@192.168.99.100

The default Docker installation login details are:

user: docker
pass: tcuser

Now that you’re on the Docker machine, you need to run the following:

sudo mkdir -p /data
sudo mount -t vboxsf -o "defaults,uid=33,gid=33,rw" mydata /data

Next, we need to tell Docker to mount this every time we start the VM.

sudo vi /mnt/sda1/var/lib/boot2docker/profile

Once you’re editing the file, add the following to the end.

mount -t vboxsf -o "defaults,uid=33,gid=33,rw" mydata /data

Once added, you can then add the volume to any container like so:

docker run --name php56 -p 80:80 -v /data/www/:/var/www/html -d localphp:5.6

Where /data/www/ is actually d:\development\data\

The post Tips for running Docker on Windows Part I appeared first on Independent technical advice for ecommerce projects based in Yorkshire.