Development Best Practices/de

Auf dieser Seite ist eine Auswahl von Programmierverfahren zusammengestellt, die bei dem Entwickeln einer Komponente, eines Plugins oder eines Moduls für Joomla! beachtet werden sollten.

Allgemeiner Leitfaden zur Entwicklung

• Die Konstante DS oder DIRECTORY_SEPARATOR darf beim Einbinden von Dateien nicht verwendet werden. Sie wird nicht mehr benötigt, wie von Christian auf php.net beschrieben.
• Die Funktion register_globals sollte nicht verwendet werden. Dies stellt ein Hohes Sicherheitsrisiko dar. Die Funktion wurde in PHP 5.3 als veraltet eingestuft und in 5.4 entfernt.
• Keinen direkten Zugriff auf die Superglobalen $_GET, $_POST, $_REQUEST, $_FILES und $_SERVER ermöglichen. Alternativ kann stattdessen JInput (typischerweise: JFactory::getApplication()->input) benutzt werden. JInput filtert die Eingabe und hilft dabei, leichter sichere Software zu entwerfen.
• Die SQL-Abfragen sollten nicht hardcodiert und Rohdaten müssen escapet in die Abfragen eingebunden werden. Immer mit JDatabase / JDatabaseQuery arbeiten. Es ist so einfach wie JFactory::getDbo()->getQuery(true).
• Keine willkürlichen Einstiegspunkte benutzen, beispielsweise .php-Dateien, die von Joomla! aus erreichbar sein müssen, direkt aus dem Internet. Diese Praxis, die typischerweise für Zahlungsabwickler und Bildoptimierer verwendet wird, ist extrem unsicher und wird ausdrücklich abgelehnt. Statt dessen sollte eine Joomla!-Komponente oder ein System-Plugin eingesetzt werden.
• Nicht das Rad neu erfinden! Wenn es eine Joomla!-Klasse gibt, die das machen kann, sollte man sie benutzen, bevor man seine eigene entwickelt. Die Chancen stehen gut, dass die Kernklasse bereits gut genug und viel besser getestet ist.
• Für die Tabellennamen sollten sinnvolle Präfixe gewählt werden. Wenn die Komponente com_foobar heißt, liegt es nahe, dass die Tabellen dem gleichen Namensschema folgen:

 // Gut
 #__foobar_something

 // Schlecht
 #__fbr_something 

 // Richtig schlecht!
 #__something

• Die Erweiterungen sollten schon mit Vorabversionen von Joomla! und/oder der „Staging“ Branch des Git-Repositorys getestet werden. Der Entwickler muss sicherstellen, dass die Benutzer der Erweiterung Joomla! sicher aktualisieren können.
• Für die Erweiterungen sollte eine Dokumentation erstellt werden. Selbst ein kurzes Video in nicht ganz so gutem Englisch ist besser als nichts.
• JText sollte verwendet werden, um die Texte der Erweiterungen zu übersetzen, anstatt sie hart zu kodieren. Die überwiegende Mehrheit der Joomla! Benutzer sind keine englischen Muttersprachler und sie werden für Ihre Umsicht dankbar sein.
• Kommentare im Code unbedingt einfügen. Nicht nur für die Leute, die damit arbeiten müssen, sondern auch für Sie selbst nach sechs Monaten.
• Den Code unbedingt unter realen Einsatzbedingungen, mit echten Datensätzen testen. Möglicherweise werden so manche Überraschungen zutage treten.

Wo sollten JavaScript-, CSS- und Bilddateien abgelegt werden, die zur Komponente gehören?

Im Root-Verzeichnis befindet sich das allgemeine Medien-Verzeichnis images, das alle Assets enthält.

In der Praxis bedeutet dies, dass Dateien, die im XML-Installationsmanifest in einem <media>-Tag, statt in einem <files>-Tag stehen, an den Ordner JPATH_ROOT/media gesendet werden. Wenn <media destination="com_foo"> angegeben wird, dann landen die Dateien in JPATH_ROOT/media/com_foo.

Es kann vorkommen, dass es eine Komponente gibt, sagen wir com_foo und dann noch ein paar zugehörige Module... für dieses Beispiel nennen wir sie mod_foo_1, mod_foo_2 und mod_foo_3. Es gibt keinen Grund, die Medienelemente für die drei Module zu paketieren, wenn sie sowieso alle gleich sind und sie von der Komponente abhängen. Der beste und logische Weg ist, sie alle an einem zentralen Ort zu platzieren, der mit einem entsprechenden Namensraum gekennzeichnet ist.

Durch das Ablegen der Medien im Medien-Verzeichnis können Templates diese mit Template-Overrides überschreiben. Die mit der Erweiterung gelieferten Dateien müssen nicht geändert werden, wodurch diese Anpassungen bei Updates verloren gehen würden. Das Laden der Medien mit den Methoden image, script und stylesheet in der JHtml-Klasse anstelle des direkten Ladens der Medien mit JDocument oder hart kodierten Tags ermöglicht ein einfache Overrides der Erweiterungsmedien. So kann die Darstellung an die jeweilige Website angepasst werden.

Weitere Informationen über die Verwendung des Medienordners für Erweiterungsmedien ist in diesem Blogbeitrag zu finden.

Wo sollten die von der Komponente generierten Dateien abgelegt werden?

Das hängt von der Art dieser Dateien ab. Es gibt zwei ausschlaggebende Faktoren:

• Die Aktualität der Datei: temporär, cache oder permanent. Temporäre Dateien sind Dateien, die sofort nach der Nutzung gelöscht werden sollten, noch bevor das Laden der Seite abgeschlossen ist. Cache-Dateien werden eine Zeit lang auf dem Server gespeichert, höchstens bis zu ihrem Verfallsdatum. Sowohl temporäre als auch Cache-Dateien können ohne Vorwarnung gelöscht werden und der Code muss dies berücksichtigen. Permanente Dateien hingegen sind nicht zum automatischen Löschen vorgesehen.
• Die Verfügbarkeit der Datei: Web-zugänglich oder Web-unzugänglich. Die webzugänglichen Dateien sind diejenigen, auf die über das Web zugegriffen werden muss, z. B. wenn eine URL in einen Webbrowser eingeben wird. Die nicht webzugänglichen Dateien sind diejenigen, auf die nicht über das Web zugegriffen werden muss.

Daraus ergeben sich die folgenden Optionen:

• Temporär, vom Web aus unzugänglich. Dazu kann man das Joomla! temp-Verzeichnis benützen. Es wird mit JFactory::getConfig()->get('tmp_path') ermittelt. Das Hardcoding des Pfades als JPATH_ROOT . '/tmp' ist eine schlechte Strategie und sollte nicht gemacht werden.
• Temporär, über das Web zugänglich. Das ist nicht akzeptabel! Temporäre Dateien sind per Definition vom Web aus nicht erreichbar. Möglicherweise wird das mit Cache. statt „temporär“ verwechselt?
• Cache, vom Web aus unzugänglich. Dazu das definierte Joomla! Cache-Verzeichnis verwenden. Mit der Konstante JPATH_CACHE findet man dessen Speicherort. Hinweis: Das Cache-Verzeichnis kann im Front-End und Back-End der Website unterschiedlich sein.
• Cache, über das Web zugänglich. Dazu ein Unterverzeichnis des Media-Ordners bestimmen. Siehe den Abschnitt über Javascript- und CSS-Dateien, das ist ein und dasselbe.
• Permanent, nicht über das Web zugänglich. Die Dateien sollten in einem Ordner unterhalb des Hauptverzeichnisses der Erweiterung abgelegt werden. Wenn wirklich gewollt ist, dass die Dateien für das Web nicht erreichbar sein sollen, sollte eine .htaccess-Datei eingefügt werden. Noch besser ist es den Benutzern die Möglichkeit zu geben, ein Verzeichnis außerhalb des Stammverzeichnisses der Website zu verwenden.
• Permanent, vom Web aus aufrufbar. Ein Unterverzeichnis des Medien-Verzeichnisses verwenden. Siehe den Abschnitt über Javascript- und CSS-Dateien, das ist ein und dasselbe.

This applies to all files handled by your Component, including files your code generates and files the users of your component upload / generate.

Finally, if you want to manage log files you are advised to use the JLog class instead of rolling your own solution.

Considerations for Javascript

When you are using addScriptDeclaration to add inline Javascript in a Joomla! page you have to be very considerate about your code's interaction with other Javascript from other extensions running on the same page. Good practices include:

• Do terminate your Javascript with a semicolon and a newline. If both are missing, your code is the source of Javascript errors as soon as another developer's code uses addScriptDeclaration after your code.
• Do make sure your Javascript code is valid and doesn't throw errors. Errors in your code will render any code after it inoperable.
• Do use try/catch blocks for risky code. If you are unsure if some code is risky just surround it with a try/catch block anyway.
• Do load your inline Javascript in the view template, not the view class (view.html.php file). Most likely it depends on the DOM which will be different when a site integrator uses a template override.

Other good practices concerning Javascript code in your extensions includes:

• Don't modify core Javascript objects including jQuery, mooTools and everything in the Joomla Javascript object. If you want to modify a core object, subclass. If you are not sure, subclass.
• Do not meddle with other developers' code. This includes moving script tags to the bottom of the page or forcibly removing script tags (e.g. removing any script tag whose source URL includes the strong "jq" – you know for whom the bell tolls).