Joomla! Documentation™

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.

Where should I place files generated by my Component?

It depends on the nature of these files. There are two decisive factors:

• The permanence of the file: temporary, cache or permanent. Temporary files are files which are supposed to be removed immediately after use, before the page load completes. Cache files will be stored on the server for a while, at most until their expiration date. Both temporary and cache files can be deleted without prior warning and your code must anticipate that. Permanent files, on the other hand, are not meant to be removed automatically.
• The disposition of the file: web accessible or web inaccessible. The web accessible files are those which MUST be able to be accessed over the web, e.g. when you type their URL in a web browser. The web inaccessible files are those which NEEDN'T be able to be accessed over the web.

This gives us the following possibilities:

• Temporary, web inaccessible. Use Joomla!'s temp-directory. You can get it by doing JFactory::getConfig()->get('tmp_path'). Hardcoding the path as JPATH_ROOT . '/tmp' is a bad practice and you must not do it.
• Temporary, web accessible. That's not acceptable! Temporary files are by definition inaccessible from the web. Maybe you really meant "cache" instead of "temporary"?
• Cache, web inaccessible. Use the defined Joomla! cache directory. Use the JPATH_CACHE constant to find its location. Please note that the cache directory may be different in the front-end and back-end of your site.
• Cache, web accessible. Use a subdirectory of the media folder. See the section about Javascript and CSS files, it's the same thing.
• Permanent, web inaccessible. Use a folder under your extension's main directory. If you really want the files to be completely inaccessible from the web remember to place a .htaccess file or, better yet, give your users the option to use a directory outside the site's root.
• Permanent, web accessible. Use a subdirectory of the media folder. See the section about Javascript and CSS files, it's the same thing.

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).