Oct 29 2019
Oct 29

Does your site have an online store? Are you looking to have sales on during the Black Friday and Cyber Monday period? Then read on - here are some quick tips to help you make the most of the sales period by ensuring that everything goes as smoothly as possible to make sure both your marketing and site are up to scratch.

Marketing / Promotion

You should have a plan in place for marketing your deals, otherwise how are people going to find out about them? This could include; promotions on your own website, promotion via social media (e.g Facebook, Twitter, Instagram) and also via email.

Social media posts and emails should be planned out in advance and posted regularly enough in the run up so that people are fully aware about when your sale will be taking place and what offers they might be able to get (be careful not to post *too much* and annoy people though!).

Having promotional material on your site homepage is a great idea as it’s the first page a lot of customers will enter the site through. Effective promotional content present in the run-up to the sales period should help ensure that you are maximising the potential number of customers that will return to check out your sales. You should ensure that any promotional messages or content remain in place until after you have finished your sales.

Analytics - Sales goals

If your site was launched at least a year ago and you have Google Analytics in place (you’d be crazy not to, right?) then you should hopefully have some reliable data that you can look at from the same sales period last year, in order to better prepare and improve upon for this year.

  • What pages / products were the most popular last year?
  • Was there anything in particular about these pages / products e.g. better design / marketing that you think helped over others?
  • Are there any sales targets that you want to set or update and improve upon? 
  • How many people visited your site more than usual? 
  • Were your SEO keywords effective, if not can they be improved upon?
  • How many users are visiting from mobile devices, is your site as mobile friendly as it can be?

Once the sales period is over for this year and you are armed with all the analytics data from this year and the previous year(s)... then you can compare and see if you have hit or missed any sales targets that you may have set. You’ll hopefully also be able to see what worked well (or not so well) in your SEO and marketing to note areas of improvement for subsequent sales you may have in the future.

Discounts

Arguably one of the most important points of what you should consider are the discounts you will be offering on the site. If you don’t usually offer discounts or use discount codes on the site, then it would be wise to test any new discount logic or discount codes on a test environment before they go live. If there are any unexpected issues with the discounts not working correctly or not behaving in the way that you’d imagine, then you (or your developer!) have a chance to fix these things before you actually put them live. 

If you have a Drupal site with e-commerce and use discounts, then you will most likely be using the commerce_discount module to manage discounts on the site. This module generally works well at a basic level, although sometimes once you try and add in some more complex discounting logic, things can sometimes stop working properly. If you are having any commerce_discount related issues on your site and need them solved, or need some bespoke development done to handle your more complex discounting logic, then get in contact with us.

Orders

A final point that you may not have thought of is in regards to the (hopeful) extra increase in orders going through the site in the sales period. Is your stock management up to date and adequate to handle the extra increase in sales? Overselling any products and having to cancel orders is not good for the customer experience and is likely to lead to negative reviews, potentially damaging your reputation. If your site is using Drupal commerce then the commerce_stock contrib module is your best friend here. Amongst other things it allows you to have "add to cart" validation that can prevent users from adding products that are out of stock, and also disable the "add to cart" button when the stock level reaches zero.

Similarly you should think about how you’ll meet your usual shipping estimates that you have displayed on your website. If you anticipate that you won’t be able to keep to your usual timings then you should display a message in a prominent place on the site that the order processing and shipping may take longer than usual during the sales period.

The (Slightly) Technical Bit - Site load, speed, optimisation.

Well before the sales period even begins you should ensure that your site is running at an optimal speed. Google’s PageSpeed Insights can be used to benchmark your site and give you a detailed analysis of page load times and where you can improve by optimising your assets, code and more. The quicker your pages load, the more likely it is that people stick around on your site and don’t get frustrated trying to access what they want - and this is all the more important when your site might get a big influx of visitors during the sales period.

Following on from the Analytics section above; using any data you have for site visitor numbers from the previous year should give you a good indication of the number of visitors that you would hopefully expect to get this year. If the larger-than-usual amount of people visiting your site caused any server timeout or other connection issues, then you should ensure to better prepare the server and site for the influx this year.

I won’t go into too much detail here as benchmarking and optimising a site is a whole article in itself! but a few key points and quick wins to help your site are:

  • Ensuring you have an appropriate caching setup on your site. On a Drupal site as a bare minimum this would include enabling CSS & Javascript aggregation and ensuring Drupal page caching is enabled. The use of a reverse proxy such as Varnish is highly recommended as well.
  • Optimising images the site is serving up with a third party image optimising service such as Kraken. This will shrink file sizes without any noticeable decline in quality.
  • Using a CDN such as Amazon CloudFront to serve up your assets.
  • Minifying Javascript. On a Drupal site this is easy with the use of a module such as Minify JS.
  • Reducing the number of DOM elements to improve page load time.

The PageSpeed Insights tool mentioned above can act as a useful tool to test the optimisations you have done so that you know when you are actually making a (positive!) difference. Hopefully your developer has already done most of the above but if not, make sure they do in good time before the sales period begins.

And finally, if you haven't already, it's a good idea to let your web team know that you are planning a Black Friday sale. This will ensure they're not surprised when the server traffic spikes and they can make recommendations (if needed) to handle the increased traffic. The last thing you want is your site falling down and costing you sales!

Nov 09 2018
Nov 09

I'll keep this short and sweet, but we thought this would be a useful tip to share with the world as a potential security issue with the combined use of File::getFileUri() and FileSystem::realpath().

Consider the following code excerpt :

$file = File::load($some_file_uri);

if ($file) {
  $uri = $file->getFileUri();
  $file_realpath = \Drupal::service('file_system')->realpath($uri);
}

Seems pretty harmless right? Load up the file from $some_file_uri , If we have a valid file then get the URI and then grab the real path.

Wrong (potentially, depending on what you do with $file_realpath).

If $file is a valid file, but for whatever reason the file is no longer physically located on disk, then $file->getFileUri() will return a blank string.

It turns out that passing this blank string $uri into \Drupal::service('file_system')->realpath($uri) will return the full webroot of your site!

Depending on what you were doing with said $file_realpath, it could then be a security issue.

We were handling a user webform submission and then sending the submission over to a CRM system... because $file_realpath was now the webroot of the site, then code that followed to archive the user submitted file ended up archiving the entire webroot and sending this over to the client's CRM system. 

Luckily in this instance, the archive was only ever available temporarily server side and then went directly to the clients own CRM system, but in another circumstance this could have easily been a very serious security issue.

Fortunately the fix is quite simple, ensure the the $uri returned from ->getFileUri() is valid by some method, before passing through realpath(). Here, I now validate the uri matches what I know it should be for the current webform submission.

if ($file) {
  $uri = $file->getFileUri();
  $webform_id = $webform->get('id');
  $submission_id = $webform_submission->get('sid')->getValue()[0]['value'];
  $valid_file_scheme = strpos($uri, 'private://webform/' . $webform_id . '/' . $submission_id . '/') !== FALSE;

  if ($valid_file_scheme) { 
    // Proceed with the rest of the code..
  }
}
May 09 2015
May 09

On April 21st, Google updated their mobile search algorithms to boost the rankings of mobile-friendly web pages, whilst conversely decreasing rankings for pages that have been designed only for large screens. This change is likely to have a big impact on many Drupal sites, and ComputerMinds have seen a surge in requests for retrofitting responsive themes onto existing Drupal sites. More information about the change - which is commonly reffered to as ‘mobilegeddon’ can be found here http://googlewebmastercentral.blogspot.co.uk/2015/04/faqs-april-21st-mob...

Due to these new changes, we have recently completed a responsive upgrade to a clients website - https://apm.org.uk - which was previously unresponsive and only displayed well at a typical desktop browser resolution (960px).

Now post upgrade, the site is fully responsive, displays and functions well across mobile devices, tablets and desktop browsers. Crucially the site is now receiving a near perfect score from the google mobile friendly test tool.

We followed a 10 step process

1 - Work out the appropriate breakpoints where the site will transition from mobile to tablet to desktop, based on your current design. For APM these were; 320px - Mobile, 768px - Tablet, 960px - Desktop. We chose not to have separate mobile/tablet/desktop style sheets, instead adding the appropriate media queries into the respective modular css files. Using the excellent breakpoints.js, we also setup the same breakpoints in Javascript that we had defined in the CSS. Breakpoints.js allows us to fire custom events when the browser enters/exits the breakpoints that we’ve defined, which in turn enables us to run specific code in reaction to the firing of these custom events.

2 - Create a mobile device specific menu that would replace the standard desktop menu. APM had a large number of links in the primary and secondary menus, so we decided to go for the “hamburger” menu approach to maximise the use of available space, showing both primary and secondary menu links on the side of the screen once the menu is activated. To achieve this - we initially hide the primary & secondary menus with css, then use javascript to move them into a separate “offscreen” div. With some CSS and Javascript trickery we can make the menu initially appear offscreen. Once the hamburger menu icon is activated we ‘slide’ it in from offscreen, keeping half of the page body visible with the menu taking up the rest of the screen. This delivers the familiar menu experience found across many mobile websites and apps. We also have a non-javascript fallback which displays the slightly restyled menus in the site header instead, to ensure people can still navigate the website with javascript disabled.

3 - Change the grid system (if applicable) from a fixed grid system into a responsive one that will work well at all different resolutions. APM had previously followed a 960px fixed grid system, consisting of 16 grid columns used to form a typical “three column” layout. We switched the site base theme to Zen 5.x to give us a responsive layout with a fluid grid system to work with. For desktop we retain the same three column layout, for tablet we made both sidebars drop into one, and mobile causes the page to go into a single column layout. All the styling for this is now fully responsive so between the various resolutions the content re-sizes and scales appropriately.

4 - Blocks - Move any blocks around in the page structure at the different breakpoints to ensure the blocks are still displayed in appropriate places. To achieve this we used a combination of CSS and Javascript breakpoints we had set up. We also had key page elements such as the menu & login blocks duplicated in the markup in different places, showing and hiding at the appropriate breakpoints. It is important to do this technique as by simply moving everything with javascript can cause a “popping” effect upon initial page load.

5 - Redesign the site header, footer to improve the appearance and functionality for mobile and tablet devices. For the APM header we dropped the header background image for a solid colour, resized and centrally aligned the logo, moved the login block and menu offscreen with new buttons at the top to activate them. The footer changes consisted of resizing the images and tidying up the styling of text and links.

6 - Tidy up, optimise any legacy CSS and update any code that may be referencing fixed pixel values for font sizes, widths, etc. Previously the APM site had all of its CSS in one single style sheet that had accumulated a lot of code over the years, becoming unmanageable. Taking a SMACCS approach, we refactored the single style sheet into modular files, removed any duplicate css, fixed old rules, changed fixed pixel font-sizes to EM’s, and fixed pixel widths into percentages.

7 - Optimise any applicable site assets, including; reducing the size of images, minifying scripts, spriting images, reducing the number of http requests & more.

8 - Upgrade image site assets where possible from bitmap to vector, to cater for the ever expanding range of high resolution devices available today. We recreated some of the assets including; menu home icon, breadcrumb separator, menu separator in the SVG file format, a vector format that scales nicely for higher resolution devices. Although supported in most of the recent desktop and mobile browsers - using SVG’s for a CSS background-image is not fully supported in all browsers so we have to add a fallback. Using the Javascript library Modernizr, we can test for SVG support, and then use a normal image as a fallback if the browser does not support SVG.

9 - Cross device, cross browser, in-depth testing of the new responsive site to ensure we achieve high compatibility with as many different devices and modern browsers as possible.

10 - Analyse the site using the Google mobile test tool, make changes including adjusting tap target sizes accordingly to improve usability. For APM this included; increasing the size of the login button, mobile menu button, input buttons, select lists, menu links, made whole teaser articles linkable, and more to enhance the mobile browsing experience.

Screenshot of the APM site on mobileScreenshot of APM site on ipad

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web