Theme Demo demo.themeshift.com/designum/
Shortcodes demo.themeshift.com/designum/features/shortcodes/
Kategorie: Dreiwerbung
-
DeSignum
-
WPML und Designum Theme
Alle Seiten übersetzt und kein Slider auf der Startseite? Nicht vergessen auch in den übersetzten Artikeln ein benutzerdefiniertes Feld mit dem Wert für „1“ für „slider“ zu setzen.
-
WPML: How To Display Different Widgets Per Language
WPML lets you translate widget titles and the body of text widgets. Sometimes, it’s not enough and you want to have completely different widgets for each language. I’ll show you how to do this using Widget Logic. Widget Logic is a plugin that allows controlling where widgets display using PHP code. You can use it to specify where widgets are allowed, including which languages they will display in.
-
WPML installieren
- Unter Plugins WPML Multilingual CMS aktivieren
- Unter Dashboard > Einstellungen > WPML Einstellungen für Sprachen und Sprachumschalter-Optionen setzen. Im konkreten Fall den Sprachumschalter auf „–keine–“ setzen da er über PHP ins Theme hardcecodet wird.
- In
header.phpdes Themes (Designum) in Zeile 25 vor dem Aufruf der Social-Schalter den Sprachumschalter aufrufen:
[php]<?php do_action(‚icl_language_selector‘); ?>[/php]
-
WordPress-Installationen vom entferneten Server auf lokal installieren
Der Transfer einer lokalen WordPress-Präsenz auf einen entfernten Server sowie das lokale Installation eines von einem entfernten Server erstellten WordPress-Site-Backups sind gängige Prozeduren im Workflow mit WordPress. Wie das alles geht (und das geht, wenngleich es komplex ist, recht einfach) wird noch Gegenstand eines eigenen Artikels sein. Hier schon mal zwei Dinge, die bei alledem schiefgehen können:
- Theme-Optionen werden eventuell nicht mit exportiert und müssen dann von Hand noch einmal eingegeben werden. Plugin- und Widgetkonfigurationen dagegen werden mit BackWPup bestens exportiert und auch bei einer lokalen XAMPP-Rekonstruktion gut wiederhersgestellt.
- Eventuell führt ein Login auf der logalen Installtion ins Backend der Server-Instanz der Site. Das kann daran liegen, dass in der config.php die site-URL definiert ist. Die sollte dann an die der lokalen Installation angepasst werden.
[php]define(‚WP_SITEURL‘, ‚http://127.0.0.1/[evtl. Unterordner der lokalen Präsenz eintragen]‘);
define(‚WP_HOME‘, ‚http://127.0.0.1/[evtl. Unterordner der lokalen Präsenz eintragen]‘);[/php]
Zu beachten: Alle Benutzer und Logindaten werden mittransportiert, sollten also auch für den Zugang ins WP-Dashboard der lokalen Installation bereitliegen.
-
Steinzeit-Alarm: Webhosting bei T-Online, Beispiel WordPress
.htaccess
.htaccess hat T-Online verboten, kann man nicht hochspielen. Weil „man so viel verkehrt machen kann damit“. Und weil das dann, das sagen die wirklich in ihrem Forum irgendwo, Supportstunden kostet, die ihnen niemand bezahlt; So schreibt das T-Home-Team imMai 2010 ins Homepagecenter-Forum
.htaccess ist zur Sicherheit der Stabilität des Servers nicht freigegeben, da über .htaccess mehr als nur HTTP-Authentifzierung geregelt werden kann (Quelle: de.wikipedia.org/wiki/Htaccess). Dieses bedeutet dann einen Eingriff in den Webserver und deswegen ist dieses serverseitig deaktiviert.
Und im Foren-Thread Werden htaccess Dateien nicht unterstützt? hieß es schon am 30. April 2009 15:43 Uhr lapidar:
.htaccess-Dateien werden aus Sicherheitsgründen nicht unterstützt. Es ist bei .htaccess-Dateien sehr leicht, einen Fehler zu machen, der den Zugriff auf eine Homepage komplett blockiert.
Am 04. Mai 2009 12:24 Uhr heißt es etwas konkreter zum selben Thema:
Wir fürchten, dass diejenigen, die sich wirklich mit .htaccess-Dateien auskennen, unter unseren Kunden in der Minderheit sind. Auf jeden Fall sind .htaccess-Dateien “support-intensiv” und damit ein Kostenfaktor. Dieser Kostenfaktor muss natürlich gegen die potenziellen Kunden aufgewogen werden, die unsere Homepage-Produkte nicht buchen, weil sie .htaccess-Dateien benötigen und einrichten können. Bis jetzt sieht diese Abwägung so aus, dass .htaccess-Dateien kein zwingend notwendiges Feature sind. Das mag sich in der Zukunft ändern – jeder Kundenbeitrag, den wir intern weiterleiten, trägt hoffentlich dazu bei – allerdings möchten wir Ihnen aktuell keine Hoffnungen machen, dass es bald eine Änderung geben wird. Mit freundlichen Grüßen, Ihr T-Home-Team.
Und das ist nur eins der Probleme. Das Resultat ist, dass es eine Pest ist, WordPress für Telekom-Kunden aufzusetzen – zum Beispiel per Transfer einer funktionierenden lokalen WordPress-Installation mit BackWPUp auf einen T-Online-Server.
Die php.ini
Bleibt das Dashboard weiß, hilft der erste Trick: Folgendes unter dem Namen php.ini im Domain-Stammverzeichnis ablegen (#):
[code]register_globals = on
memory_limit = 64M
post_max_size = 24M[/code]Es läuft ein altes PHP – 4.8 zum Beispiel
Das kratzt WordPress (noch) nicht, allerdings versagen manche Plugins (wie das schöne WP-Typography) den Dienst. Dabei kann man dem T-Online-Server ganz leicht sagen, dass man eine höhere PHP-Version nutzen will. Dazu der T-Online Service: „Vermutlich wird PHP 5 nicht ausgeführt, weil Sie für Ihre Domain eine Weiterleitung eingerichtet haben. Versuchen Sie bitte einmal folgendes: Erstellen Sie eine PHP-Datei mit dem Inhalt
[php]<?php $h = fopen (".config", "w");
fwrite ($h, "\nPHP 5\n"); fclose ($h); ?>[/php]Laden Sie die Datei unter einen beliebigen Namen (z. B. „fix.php“) in das Verzeichnis auf Ihrem Speicherplatz hoch, auf das Ihre Domain weitergeleitet wird und rufen Sie sie einmalig unter www.<Domain>.de/fix.php auf. Wird dann auch auf der Domain als Standard PHP 5 verwendet? Die Datei fix.php können Sie anschließend löschen. Mit freundlichen Grüßen – Ihr T-Home-Team.“ (#)
„Hübsche Links“ dank mod_rewrite und .htaccess
Kurz und schmerzlos: das kann man bei T-Online vergessen, mod_rewrite, das für die Umsetzung der entsprechenden Befehle im WordPress-Dashboard (Dashboard > Einstellungen > Permalinks > Benutzderdefinierte Struktur) zuständig ist, ist bei T-Online genauso abgeschaltet wie .htaccess. Hierzu ein Forenbeitrag:
Ich habe das eindeutig mit T-Online klären können:
- keine .htaccess Möglichkeit (auch nicht kaufbar, man muss ein Server Paket nehmen, um das zu bekommen)
- kein mod_rewrite außer auf Server Paketen
- keine benutzerdefinierten Fehlerseiten
Somit sind keine Permalinks möglich (wie auch immer man das hätte tricksen können) und ich habe einen Bekannten deswegen wieder zu 1und1 umziehen lassen. Spart auch noch Geld, denn 9,99 € für nix oder 6,95 € für ein voll funktionierendes WP sind schon ein gewaltiger Unterschied.