WordPress Media Upload has grown mature

The WordPress Media Upload has grown up: Since version 3.3 there is only one button left on the edit form – A big usability plus. Additionally, the lightbox/iframe integration now supports drag&drop uploads with modern browsers (firefox, chrome) and an acceptable multiple file upload for the rest of the browser-bunch.

One step forward

One of my intentions for YAPB was to make the fileupload as easy as can be. For a photoblog, the image upload was the most important thing just after entering the title. So i introduced a new file-upload meta-box just below the title on post/page add/edit forms. Over the years, I got a lot of positive feedback regarding this feature and i planned to keep with this with the next generation of the plugin, which will probably use the native WordPress fileupload-feature so everything becomes much more standardized.

WordPress Inline Mediaupload

Inline Mediaupload also introduces a new meta-box on post/page forms which directly contains the media-upload.php iframe otherwise only reachable via button/lightbox:

The iframe automatically resizes smoothly with its inner content thus hiding the iframe-nature of the content.

Additionally, the plugin introduces a new meta-box area to the forms allowing you to move any meta-box just below the title input field – that’s just my personal favorite location for placing the new upload-box ;-)

Support Open Source

If you like this plugin and want to honor the time I spent in creating/elaborating/updating it since December 2011 – Feel free to donate a small ammount via Paypal!

Der erste Eindruck

Mein erster Eindruck ist durchgehend positiv:

Das CMS stellt ein Agentur-Framework für die Entwicklung komplexer Seiten dar: Es basiert zum größten Teil auf dem PHP-Framework Zend, mit dessen Hilfe ein relativ gut durchdachtes MVC-Pattern implementiert wurde.

Im Backend stellt Pimcore einige sehr interessante Feature via ExtJS zur Verfügung, was eine sehr moderne Admin-Oberfläche ermöglicht. Der Entwickler kann zB. via Drag & Drop sehr einfach neue Data Access Objects (DAO) erstellen und untereinander verknüpfen. Diese stellen in Folge die Datenstruktur der Website. Hier bekommen wir die Grundidee von zB. Drupal in einem modernen und durchdachtem neuen Gewand präsentiert.

Das Backend erlaubt out-of-the-box auch die Deklaration von Parent-Klassen für im Backend definierte Klassen: Damit lassen sich mit Hilfe eines guten Programmierers auch komplexe Domains darstellen.

Klassifizierung

Pimcore schätze ich derzeit primär als Agentur-Website-Frameset ein: Es wird auf jeden Fall ein kompetenter PHP-Entwickler benötigt, um Kundenseiten bottom-up aufzubauen.

Hobby-Programmierer haben mit Pimcore weniger Freude, da es erstens idealerweise auf einem dedicated Server läuft, auf dem man zB. benötigte PHP Module deployen kann. Zusätzlich muß man schon für sehr einfache Seiten anfangen, eigene PHP-Controller zu programmieren, bevor irgendwas angezeigt wird: Hier wird out-of-the-box nichts zur Verfügung gestellt.

Hat man diese Ressourcen (PHP-Programmierer) allerdings zur Verfügung und die Hürden der sehr Fachpublikum-orientierten Dokumentation überwunden, kann ich das System auch jetzt schon 100%ig empfehlen: Mit kurzer Einlernzeit durch einen Pimcore-Kundigen lassen sich auch komplexe Themengebiete sehr effizient darstellen.

Gute PHP Programmierer lassen sich definitiv durch das schön strukturierte Zend-Framework und das kompetent implementierte MVC-Pattern überzeugen.

Verbesserung möglich und nötig

Grundsätzlich zeichnen sich erfolgreiche Open-Source-Projekte derzeit aus meiner Sicht durch eine möglichst breit gestreute Stakeholder-Gruppe aus: Je weiter die Userbasis, desto mehr Interessenten und Entwickler finden sich, die Bugs und Feature Requests einstellen wie auch analysieren/beheben/programmieren.

Pimcore verschenkt hier aus meiner Sicht derzeit definitv Potential und ist aus Open-Source-Sicht strategisch nicht 100%ig richtig positioniert: Um hier das Momentum einer starken Entwicklergemeinde aufbauen zu können, ist das System meiner Meinung nach noch zu anspruchsvoll bezüglich der Infrastrukturanforderungen.

Zusätzlich bietet es noch nicht den nötigen Level an Trivialisierung, um mäßig ausgebildete PHP-Programmierer anzuziehen.

Senior-PHP-Entwickler als Target Audience?

Die Macher von Pimcore sollten sich meiner Meinung nach etwas mehr Gedanken um die Zielgruppe machen: Wie bekommt das CMS strategisch die meiste Aufmerksamkeit? Wie kann ich möglichst viele Open-Source-Entwickler in das Projekt einbinden? Wie fördere ich auch nicht so begabte/ausgebildete PHP-Prgammierer, ihren Beitrag zu dem Projekt beizutragen?

Ich würde hier Ansätze von Open-Source-Projekten wie zB. WordPress analysieren und implementieren: Diese verstehen es vorzüglich, zB. das Templating vom Kern-System zu trennen und sauber zu Dokumentieren. Das Basis-System selber läuft auf einer möglichst breiten Systemlandschaft und ist sehr einfach zu installieren und aktuell zu halten.

Resultat:

• Tausende von Programmieren, die täglich neue Plugins/Templates zum Projekt hinzufügen.
• Millionen von Nutzern; Das CMS wird täglich von unzähligen Nutzern weiter empfohlen, runtergeladen und installiert.
• Open Source Momentum

Fazit

Schafft es das Entwicklungsteam, die verschiedenen Hebel der Open Source Entwicklung optimal zu bedienen, sollte Pimcore meiner Meinung nach wie eine Atomombe einschlagen: Grundsätzlich bietet das System alles, was sich ein gut ausgebildeter PHP-Entwickler derzeit nur wünschen kann – Allerdings fehlt noch das richtige Open Source Momentum.

Create a page template file

So let’s start with our new page template: Create a file named tpl.yapb.mosaic.php in your current theme folder.

Throw in some WP Metadata

As a first step we define a standard PHP comment at top with meta data so WordPress can identify this file as template:

<?php /* Template Name: YAPB Photo Mosaic Page (Prototype) */ ?>

Create some infrastructure

Now some default infrastructure for WP templates like calling the header, starting the WP loop, displaying the page title and content:

<?php
  get_header(); ?>
  <!-- Let's start the WordPress loop -->
  <?php if (have_posts()): while (have_posts()): the_post(); ?>
    <?php global $post; ?>
    <div class="post">
      <h1><a href="<?php echo get_permalink() ?>"><?php the_title(); ?></a></h1>
      <?php the_content('read more...'); ?>

Define what you want

To display the thumbnails of all our photos, we need to know what we want to fetch exactly. In my case, i assign each photoblog post to a special category “photoblog”. That category is configured in YAPB – so i can ask for it’s id and get all (or at least the last 1000) posts of that category with a simple WordPress function. Additionally i use this php part to define the format of the thumbnails i want to display on this page:

<?php
  // Let's get the last 1000 photoblog entries
  $photoblog_posts = get_posts( 'category=' . get_option('yapb_default_post_category') . '&numberposts=1000' );
  // Let's define the needed thumbnail format
  $thumbConfig = array( 'h=80', 'q=100', 'fltr[]=usm|60|0.5|3' );
?>

Loop through the fetched posts

Since we should have all needed posts now, we simply cycle through all of them, get the image and display the thumbnails. In this sample i use a unordered list as structure for the images:

<ul>
  <?php foreach($photoblog_posts as $photoblog_post): ?>
    <?php if (!is_null($image = YapbImage::getInstanceFromDb($photoblog_post->ID))): ?>
      <li><a title="<?php echo $photoblog_post->post_title ?>" href="<?php echo get_permalink($photoblog_post->ID) ?>"><img src="<?php echo $image->getThumbnailHref($thumbConfig) ?>" width="<?php echo $image->getThumbnailWidth($thumbConfig) ?>" height="<?php echo $image->getThumbnailHeight($thumbConfig) ?>" alt="<?php echo $photoblog_post->post_title ?>" /></a></li>
    <?php endif ?>
  <?php endforeach ?>
</ul>

Close the previously created infrastructure

To cleanly finalize the page template we now close the previously opened WordPress loop and call the footer.

<?php endwhile; endif; ?><!-- end of the WP loop -->
<?php get_footer(); ?>

The complete file may be found in this .zip file (275 KB).

Finally just use the new page template

To use the page template, just go to your admin panel, write a new page and choose your newly created page template – Voila: You have your first YAPB mosaic page!

Was muß ich schon Anfangs wissen, um das Plugin am Ende auch wirklich ohne große Arbeit Übersetzen zu können (Ich brauche keinen Abschließenden Aha-da-hab-ich-an-der-Realität-vorbeiprogrammiert Effekt).

Naja – WordPress benutzt das freie GNU-Gettext (bzw. hier ein Link zur Gettext-Seite selber), welches grob folgende Arbeitsschritte vorraussetzt:

1. Alle zu übersetzenden Texte im Quellcode durch Funktionsaufrufe ersetzen
   zb. print(‘This is english’); durch print(__(‘This is english’, ‘pluginname’)); wobei beim Entwickeln wirklich Englisch verwendet werden sollte.
2. Ein Tool wie zB. poEdit drüberlaufen lassen, alle diese Textschnipsel herausholen lassen und in eine .po-Datei speichern. Diese agiert als Resourcencontainer für nicht übersetzte Textschnipsel.
3. Diese jetzt Schritt für Schritt in die gewünschte Sprache übersetzen
4. Das Ergebnis zu einer .mo-Datei (zB. pluginname-de_DE.mo) kompilieren und abspeichern

WordPress selber erlaubt dann die Einbindung dieser Textdomain und ersetzt dann alle so vorbereiteten Textschnipsel durch die deutschen Übersetzungen, wenn der User das so in WordPress eingestellt hat.

Sollte der Benutzer dann eine noch nicht übersetzte Sprache verwenden, wird standardmäßig der Englische Text angezeigt, der ja immer noch im Quelltext vorliegt.

Fazit: Selbst wenn dies wieder mal der falsche Ansatz ist und ich Yapb als eigenständige WebApplikation entwickle, hab ich wieder was dazugelernt: Ein schöner Ansatz für Übersetzungen. Die Übersetzung geht gut von der Hand, wenn man statt den Commandline-Tools der GNU Foundation mit poEdit arbeitet. Ich denke, dass jedes seriöse Übersetzungsbüro .mo-Dateien akzeptiert.

More Infos: Falls sich jemand für das Thema interessiert und schnell in die Materie kommen möchte, kann ich diese beiden Artikel empfehlen:

• Die Anfangsseite auf wordpress.org
• Ein sehr schöner Artikel auf zyblog.de beschreibt, wie man WordPress Themes lokalisiert – Der beschriebene Workflow läßt sich natürlich auch auf Plugins anwenden und enthält auch einen Link auf folgenden Artikel:
• Erstellen einer Sprachdatei mit poEdit auf wordpress.de

Zusammen ergeben die 3 Artikel ein schönes Bild – Nach ein bisschen lesen und nachmachen sollte jeder in der Lage sein, eigene Übersetzungsdateien zu erstellen und zu benutzen.

• PHP 4.4.1
• GDLib 2.0.33
• Freetype2

Dank dem Freetype-Plugin funktioniert jetzt auch die Captcha-Abfrage bei den Kommentaren im Photoblog, was ich persönlich ziemlich lässig finde. Zusätzlich habe ich einiges über Linux-Compiling, dessen Tücken und natürlich über den famosen safe_mode von PHP gelernt. Mein Fazit über den safe_mode ist hier sehr schön zusammengefasst: Artikel zum Safemode auf support.webedition.de