5 häufige Fehler, die Sie mit Ihrer Website machen

Fünf häufige Fehler, die Sie bei Ihrer Website machen

Andrew Melck Jeffrey A. “jam” McGuire Solutions Architect Manager of Community Affairs [email protected] [email protected] @drewmelck @horncologne

Acquia Professional Services

•  Drupal Jumpstarts

•  Architektur-‐Workshops

•  Discovery-‐Workshops

•  Site-‐Audit •  Performance-‐Audit

•  Sicherheits-‐Audit •  Vor ort Consulting

Dieses Webinar

Fünf Kategorien häufiger Fehler, die wir bei Site-‐Audits oft finden:

•  Architektur (Content , Funktionalität, Darstellung)

•  Sicherheit

•  Performance

•  Infrastruktur

•  Website Life Cycle (Entwicklung, Deployment, Aktualisierung)

“Der Seiten-Inhaltstyp Article ist dem Typ News ähnlich. Ein paar Monate lang haben wir einfach Article benutzt, um besondere Nachrichten auf der Website darzustellen.”

“Wir wollten dieses Template ändern, damit es besser passt, also haben wir school_location und teacher_city benutzt.”

Content-Architektur

“Redakteure verstehen nicht, was sie erstellen sollen.”

Content-‐Architektur Symptome

•  Ähnliche Content-‐Typen

•  Felder nicht wieder benutzt

•  Content-‐Typen fast ohne Nodes

Fehlersuche

•  Beachten Sie die Field-‐Report-‐Seite. •  Struktur der Content-‐Typen •  Einfache Datenbank-‐Anfragen -‐> Select count(*), type from node group by type

Content-‐Architektur Best Practices

•  Planen Sie Ihre Content-‐Architektur im Voraus – es ist der vermutlich wichtigste Teil Ihrer Site.

•  Überlegen Sie gut, bevor Sie ein neues Feld oder einen neuen Content-‐Typ anlegen.

•  Standardisieren Sie Content-‐Typen und Felder, und verwerten Sie sie wieder.

•  Hilft bei der Wartung

•  Verbessert die Nutzer-‐Experience

•  Verbessert die Performance

“Der Ergebnisse-Block im Sportteil? Ein bisschen PHP-Code kontrolliert die Sichtbarkeit in der Block-Konfiguration...”

“Wir brauchen diese node_load() in preprocess_page, weil wir diese Nodes auf der Homepage darstellen wollen.”

Darstellungs-Architektur

“Views_london, views_paris, views_lisbon zeigt freie Stellen in diesen Städten.”

Darstellungs-‐Architektur Fehlersuche

•  Lernen Sie, wie Seiten aufgebaut sind.

•  Betrachten Sie alle Views und ob sie wieder verwertbar sind.

•  Wie viele selbstgebauteTemplates haben Sie?

•  Wieviel Logik beinhalten Ihre Templates

•  Wie leicht können Sie Themes wechseln?

•  Wie lange dauert es, für Ihre Site ein ganz neues Design anzulegen?

Darstellungs-‐Architektur Best Practices

•  Halten Sie Logik und Präsentation gut auseinander.

•  Kein Logik-‐Code in Template-‐Dateien (*.tpl.php)

•  Selbstgebaute Logik in Modulen

•  Selbstgebaute Logik in preprocess-‐Funktionen, falls nötig

•  Individualisieren Sie die richtigen Templates.

•  Das Theme Developer Module kann helfen (drupal .org/project/devel_themer)

•  Base Theme: Starten Sie mit einem guten Fundament für die Darstellung und Präsentation, und bauen Sie darauf auf.

Site-‐Architektur Symptome

•  Installierte Module

•  Anzahl der Module, die nicht genutzt werden

•  Gehackter Core und Module

•  “There‘s a module for that” – heißt noch lange nicht, dass Sie es auch brauchen!

•  Module, die nicht das tun, wofür sie geschaffen wurden

•  PHP Code in der Datenbank

“Das ist ein Modul, das wir selbst gemacht haben, um ad hoc Formulare zu machen und sie per E-Mail an die Site Admins zu schicken!”

“Dieses selbstgebaute Modul erstellt kleine, versteckte Tokens, die auf unserer Site SPAM kontrollieren.”

Das Rad neu erfinden

“Wir dachten, wir bräuchten Content-Übersetzungen, aber jetzt gibt‘s unsere Website doch nur auf Englisch.”

“Im Moment haben wir nur einen Nutzer-Typ, aber irgendwann brauchen wir vielleicht mehr Rollen, darum haben wir jetzt schon content_access.”

“Wir benutzen das Authcache Modul, um die Seiten für unsere 20 Journalisten schneller zu machen.”

Zu komplex

Site-‐Architektur Fehlersuche

•  Stellen Sie die Anzahl der Module der Funktionalität, die sie bieten, gegenüber.

•  Überlegen Sie, ob alle Module effektiv genutzt werden oder ob es auf drupal.org bessere gibt.

•  Benutzen Sie das hacked! Modul (http://drupal.org/project/hacked), um die verwendeten Code-‐Versionen zu prüfen.

Selbstgebaute Module Symptome

Code-‐Standards werden nicht beachtet.

•  Eine Warnung vor dem, was da noch kommt?

Die richtigen Hooks werden nicht genutzt.

•  Übermäßiger Gebrauch von hook_init, hook_nodeapi

Die API wird nicht verwendet.

•  Etwas neu erfunden, das Drupal schon gut macht

Fest kodierte Strings (nids, tids, vids, urls).

Aller Code in .module Datei

Best Practices Finden Sie eine Balance zwischen eigenem Code und Contributed Code / wiederverwertbaren Lösungen.

•  Kann statt Query nicht auch ein View benutzt werden?

•  Kann die Seite nicht auch mit Context oder Panels erstellt werden?

•  Kann diese Aktion nicht auch mit einer Rule kontrolliert werden?

Finden Sie die besten Module für Ihren Zweck und lerne sie richtig kennen. Nutzen Sie sie so gut wie möglich.

•  Suchen und planen Sie vor der Umsetzung. Testen Sie in kurzen Sprints.

•  Die Architektur einer Site verändert sich im Lauf der Zeit – bewerten Sie sie regelmäßig neu.

Was wir auf Ihren Websites gefunden haben!

“Dieser Webservice-Pfad kann gar nicht gefunden werden, der braucht keine Authentifizierung. Nur die Mobil-App nutzt ihn.”

“Um auf diese Seite zu gelangen, muss man schon Administrator sein.”

“Wir sind die einzigen, die Zugriff auf den Server haben, daher brauchen wir uns keine Sorgen machen.”

Sicherheit

Sicherheit Grundlegende Probleme

•  Core und Contributed Module nicht auf dem neuesten Stand

•  Schlechte Konfiguration

•  Nutzerberechtigungen, die es nicht geben sollte

•  Admins haben einfache Passwörter (ähnlich dem Nutzernamen, gehackte E-‐Mail-‐Konten)

•  Datei-‐Upload wird nicht überprüft

•  Code Repository/Docroot enthält kleine “Geschenke” •  DB-‐Dumps, Dateien mit Informationen, die dort nicht hingehören

Sicherheit 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'

);

Sicherheit CSRF – Cross site request forgery

•  HTML Email

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

•  HTTP Post to forms

•  Sie erwarten, dass die Anfrage von Ihrer Site kommt – sie kann aber von irgendwo herkommen.

•  Drupal schützt gegen Atttacken mit Tokens sowie Form API.

Performance Was Ihre Website macht

•  Wie lange dauert es, bis Seiten geladen sind (common lists, node pages, Homepage)?

•  Warum dauert es so lange? DB queries, application requests?

•  Was ist mit Edge-‐Cases? Clear cache zum Beispiel?

•  Was ist Ihre Caching-‐Strategie?

•  Was sagen Ihnen Ihre Logs?

Performance •  Wie lange dauert es, bis Seiten geladen sind?

•  Devel kann sofort einige Probleme anzeigen.

•  XhProf findet den Rest.

•  NewRelic (newrelic.com) ist Gold wert!

•  Warum werden CPU und Arbeitsspeicher verschwendet?

•  Typischerweise

•  Komplexe Anfragen dauern zu lange.

•  Functionen werden zu oft aufgerufen.

•  Edge-‐Cases häufen sich.

Performance Warum ist die DB so langsam? Warum gerade jetzt?

•  Datenbanken nicht skalierbar

•  Komplexe Anfragen ohne Index-‐Verwendung

•  Automatische komplexe Anfragen

SELECT 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 Vor Caching optimieren

• “My Site is Slow” -‐ Vortrag von Drupalcamp Madrid und London

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

Performance Kann es gecached werden?

•  Stellen Sie sicher, dass Caching und Aggregation (JS/CSS) eingerichtet sind. Prüfen!

•  Caching-‐Strategie überprüfen:

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

•  Stellen Sie sicher, dass Caching Ihnen aktiv hilft.

•  Cache nicht zu oft löschen; lass es “aufwärmen”.

•  Sicherstellen, dass es auch häufig genutzt wird.

•  Überprüfen Sie die Komplexität, bevor Sie sich für eine Richtung entscheiden.

Infrastruktur Hier endet Ihre Website..

•  Wie groß ist richtig? Und wie wachsen?

•  Sind alle Server gut getunt?

•  Apache / PHP

•  Mysql

•  Varnish

•  Was sagen Ihnen Ihre Logs?

Infrastruktur

•  my.cnf

•  Innodb_buffer_pool = 1024M

•  Passen Sie Grenzwerte an Ihre Ressourcen an.

•  http://mysqltuner.pl

•  Ihr langsamster Engpass ist Ihr Engpass insgesamt.

“Unser DB Server hat 48Gb Arbeitsspeicher. Genug, um alle Anfragen zu bearbeiten!”

Infrastruktur

“Wir brauchen nicht so viele Web-Server. Da wir Reverse Proxy vorgeschaltet haben, wird der meiste Verkehr gecached.”

Infrastruktur

“Unsere externe Firewall hat alle Attacken im Griff. Wir benutzen keine extra Firewall für die Server.”

•  50/70% aller Attacken sind intern. Remote Connections mit der DB, Memcached, Solr sollten nicht erlaubt werden.

•  Details gehen in schnelllebigen Umgebungen oft verloren.

Website Life Cycle Dies ist der Großteil der Arbeit!

•  Wie sieht Ihre Deployment-‐Architektur aus?

•  Wie leicht kann sie geändert werden?

•  Wie testen Sie Änderungen?

•  Wie entspannt verlassen Sie Ihren Schreibtisch?

“Wir kopieren den Code einfach direkt zum Server mit FTP.”

“Jeder Entwickler kann eine Kopie aus Production machen und sie auf seinem Laptop installieren.”

“Finger weg von dem Modul. Wir haben das Original gerade ein bisschen abgewandelt.”

Deployment

Development Kontrollieren Sie Ihren Code!

Alle Teile des Code sollten unter VCS sein.

•  Git, Mercury, Bazaar, SVN, CVS

•  In Backup-‐Ordner kopieren ist nicht VCS.

•  Commit-‐Nachrichten sollten nicht leer sein…

•  Urlaubsbilder haben unter VCS nichts zu suchen.

•  Ihre Datenbank-‐Dumps gehören da auch nicht hin.

“Das können wir nur in Production testen.”

“Klar haben wir eine Staging-Umgebung. Aber die Daten sind vom letzten Sommer.”

“Manchmal gibt‘s Probleme beim Upgrade. Aber wir haben ja noch das Backup.”

Aktualisierung/Wartung

Umgebungen Einmal erstellt, immer wieder genutzt!

•  Es sollte mehrere Umgebungen geben.

•  Development, Staging und Production.

•  Deployment aus VCS sollte möglich sein!

•  Umgebungen sollten aktuell und zugänglich sein.

•  Umgebungen sollten so nah an der Realität sein wie möglich.

•  Umgebungen sollten leicht zu verwerfen und zu duplizieren sein.

Aktualisieren/Wartung Dies ist der Großteil der Arbeit!

•  Seien Sie auf Veränderungen vorbereitet.

•  Meistens haben Sie keine Kontrolle darüber!

•  Achten Sie auf Sicherheits-Updates.

•  Lesen Sie regelmäßig Ihre Logs.

•  Überdenken Sie regelmäßig die Architektur Ihrer Website.

Kostenloser Site-Audit ?

http://www.acquia.com/insight

FRAGEN ?

5 häufige Fehler, die Sie mit Ihrer Website machen

Technology

Transcript of 5 häufige Fehler, die Sie mit Ihrer Website machen