5 Common Mistakes you are making on your Website

Hernâni Borges de FreitasTechnical Consultanthernani@acquia.com@hernanibf

About me

• .PT / Uk

• Acquia Professional Services EMEA

• Technical Consultant

• Drupal* many things

• Passionate about web and communities

• Travel lover

Acquia Professional Services

• Drupal Jumpstarts

• Architecture Workshop

• Discovery workshops

• Site Audit

• Performance Audit

• Security Audit

• On-site Consulting

Site Audit

• During limited time we look to your website assuring it is following best practices and do not present risks regarding:

• Architecture (Content , Functionality, Display)

• Security

• Performance

• Infrastructure

• Website Life Cycle (Development, Deployment, Maintenance).

This webinar

• Common mistakes we found in site audits looking to 5 categories:

• Architecture (Content , Functionality, Display)

• Security

• Performance

• Infrastructure

• Website Life Cycle (Development, Deployment, Maintenance).

“The page content type article is similar to news. We just used it during some months to create special news in homepage.”

“We needed to change this template because we wanted to show everything in that location and we use school_location and teacher_city.”

Content architecture

“Editors don’t understand what to create. ”

Content architecture

Symptoms

• Similar content types

• Fields not reused

• Content types with almost no nodes

Chasing it

• Take a look at field report page.

• Content type structure.

• Simple database queries

• Select count(*), type from node group by type

Content architecture

Best practices

• Plan your content architecture ahead. This is probably the most important part of your site.

• Think before creating a new field or content type.

• Reuse and standardize as many content types and fields as possible.

• This will help in maintenance

• This will help in user experience

• This will help in performance

“The scores block in the sports section ? Some PHP code is controlling its visibility in block configuration..”

“We need those node_load() in preprocess_page because we need to show those nodes in homepage.”

Display architecture

“Views_london, views_paris, views_lisbon shows jobs available in these cities”

Display architectureChasing it

• Understand how pages are build.

• Look at views and how reusable they are.

• How much custom templates do you have?

• How much logic do you have in templates.

• How easy is to switch theme (mobile, special occasions?)

• How long does it take to produce a totally new design in your site?

Display architecture

Best practices

• Separate very well what is logic and what is presentation.

• No code handling logic in template files (*.tpl.php)

• Custom logic in modules

• Custom logic in preprocess functions if needed

• Customize the right templates.

• Theme developer module can help.

• Start with a solid foundation to manage display and presentation, excel on it.

Site architecture

Symptoms

• Modules installed

• Number of modules that are not useful at all.

• Hacked core and modules

• “There is a module for that” – does not mean you need to use it!

• Modules used for things they were not designed to do.

• PHP Code in database

“This is a custom module we designed to create forms on the fly that can be sent by email to site admins!”

“ That custom module adds small hidden tokens to control SPAM in our website.”

Reinventing the wheel

“We thought we needed content translation but in the end our website is just in english.”

“Right now we only have one type of users, but in the future we might need to have more roles, so we already have content_access.”

“ Authcache module is used to speed up pages for our 20 journalists.”

Extra complexity

Site architecture

Chasing it

• Evaluate number of modules and functionality they are providing.

• Evaluate if all modules are effectively used or if better alternatives are present from drupal.org

• Use hacked! module (http://drupal.org/project/hacked) to compare code versions used.

Custom modulesSymptoms

• Not following coding standards

• Can be a warning for what is coming…

• Not using the right hooks

• Excessive usage of hook_init, hook_nodeapi

• Not using the API

• Reinventing something that Drupal is already doing well

• Hardcoded strings (nids, tids, vids, urls).

• All code in .module file

Best practices

• Balance custom code / contributed code or reusable ways of solving problems.

• Couldn’t that query be a view ?

• Couldn’t context or panels create that page?

• Couldn’t that custom action be controlled by a rule?

• Find the best modules for your use case and excel on using them.

• Search and plan before implementation. Test it in short sprints.

• A site architecture is something that changes overtime, reevaluate if periodically.

The things we found in your website!

“ That webservice path is impossible to find, it does not need authentication. Only the mobile app uses it.”

“ You would need to be a administrator to access that page.”

“ We are the only ones we can access the server, therefore we are just too worried about it.”

Security

Security

Basic problems

• Not updated core and contributed modules.

• Bad configuration

• Users have permissions to do things they shouldn’t

• Admins have easy passwords (similar to usernames, hacked email accounts..)

• File upload is not checked

• Code repository contain extra gifts

• Database dumps, files with information that should no be there ..

Security

SQL Injection

• db_query(“select from table where id=$_GET[‘id’]”);

• Example.com/index.php?id=1;drop database yoursite;--

XSS – Cross site scripting

• <?php echo “Your number is “. $_GET[‘id’]; ?>

• Index.php?id=<script>alert(“UAAAT??”);</script>

CSRF – Cross site request forgery $items[‘admin/cookies/%/delete’] = array('access callback' => 'user_access','access arguments' => array('access cookies'),'page callback' => 'cookie_delete'

);

$items[‘admin/cookies/%/delete’] = array('access callback' => 'user_access','access arguments' => array('access cookies'),'page callback' => 'cookie_delete'

);

Security

CSRF – Cross site request forgery

• HTML Email

• <img src=“http://example.com/admin/cookies/10/delete” />

• HTTP Post to forms

• You expect the request to come from your site but it can come from anywhere

• Drupal protects against both attacks using tokens and Form API

Performance

What is your website doing

• How long do most pages take to load (common lists, node pages, homepage?)

• Why do they take so long? DB queries, application requests?

• What about edge cases? Clear cache for instance?

• What is your caching strategy?

• What are your logs telling you?

Performance

• How long do most pages take to load ?

• Devel can show immediately some problems

• XhProf can do the rest

• NewRelic (newrelic.com) is pure gold!

• Why is CPU and memory wasted?

• Typically

• Complex queries that take too much time

• Function called too much times

• Edge cases that are happening all the time

Performance

Why is the database so slow? Why is only slow now?

• Databases not optimized to grow

• Complex queries made by without indexes usage

• Complex queries made automaticallySELECT node.nid AS nid, users.picture AS users_picture, users.uid AS users_uid, users.name AS users_name, users.mail AS users_mail, node.title AS node_title, GREATEST(node.changed, node_comment_statistics.last_comment_timestamp) AS node_comment_statistics_last_updated FROM node node

INNER JOIN users users ON node.uid = users.uid INNER JOIN node_comment_statistics node_comment_statistics ON

node.nid = node_comment_statistics.nid ORDER BY node_comment_statistics_last_updated DESC

Performance

Is using InnoDb always better?

• Use views lite pager module instead, if possible.

SELECT COUNT(*) FROM (SELECT DISTINCT node.nid AS nid FROM node node LEFT JOIN og_ancestry og_ancestry ON node.nid = og_ancestry.nid INNER JOIN users users ON node.uid = users.uid INNER JOIN node_comment_statistics node_comment_statistics ON node.nid = node_comment_statistics.nid WHERE og_ancestry.group_nid = 5 ) count_alias

Performance

Optmizing before caching

•“My Site is Slow” - talk in Drupalcamp Madrid/ Drupalcamp London

•http://www.slideshare.net/hernanibf/london2013

Performance

Can it be cached?

• Assure caching and aggregation are set. Yes, look at it!

• Review caching strategy:

• https://www.acquia.com/blog/when-and-how-caching-can-save-your-site-part-2-authenticated-users

• Guarantee caching is effectively helping you.

• Don’t clear it too often.

• Not used only by a minority.

• Evaluate complexity before choosing a direction.

Infrastructure

This is where your website ends..

• What is the right size? How do you grow?

• Are the different servers well tuned ?

• Apache / PHP

• Mysql

• Varnish

• What are your logs telling you?

Infrastructure

• My.cnf

• Innodb_buffer_pool = 1024M

• Adjust limits according to your resources.

• http://mysqltuner.pl

• Your slowest bottleneck represents your overall bottleneck.

“Our DB Server has 48Gb of memory. Enough to handle all requests!”

Infrastructure“We don’t need that many web servers.

As varnish is set in front and working as a reverse proxy, most of the traffic will be cached.”

Infrastructure

“Our external firewall controls all sort of attacks. We don’t use any specific firewall in the servers.”

• 50/70% of attacks are internal. Remote connections with DB, Memcached, Solr should be forbidden.

• Hard to remember about details on fast moving environments.

Website Life Cycle

This is going to be must of the work!

• What is your deployment architecture?

• How hard is it too change?

• How do you test changes?

• How relaxed do you leave your desk?

“We just copy the code directly to the server by FTP.”

“Any developer can just take a snapshot from production and install on their laptop.”

“Don’t touch that module. We just did some changes from what it was originally.”

Deployment

Development

Control your code!

• All piece of code should be under VCS.

• Git, Mercury, Bazaar, SVN, CVS

• Copying to backup folders is not VCS.

• Yes, log messages should not be empty…

• No, your holidays pictures should not be under VCS.

• No, your database dumps shouldn’t also be there.

“We can only test that in production.”

“Yes we have a staging environment. But its data is from last summer.”

“Sometimes problems occur when we upgrade. But we have always a backup.”

Maintenance

Environments

Do once, prepare many!

• Several environments should exist

• Development, Staging and Production.

• Should be possible to deploy from VCS to them!

• Environments should be up to date and accessible

• Environments should be as possible similar to real life

• Environments should be easy to destroy and replicate

Maintenance

This is going to be most of the work!

• Be prepared for changes

• You don’t control them most of times!

• Pay attention to security updates

• Review your logs periodically

• Review periodically website architecture

Free site audit ?

QUESTIONS ?