Beiträge von DeepSpace9

Gleich Update auf WordPress 4.3 "Billie" installiert - hat reibungslos funktioniert. Allerdings läuft leider die angekündigte Funktion eines Icons für die Website noch nicht richtig: Das Favicon ist nur in Chrome zu sehen, aber nicht in Firefox oder IE. Die angekündigten komfortablen Einstellungen fehlen, so dass keine Vorschau etwa für mobile Geräte existiert. Nächstes Update?

Trotzdem vielen Dank an die Entwickler! WordPress - mehr und mehr genial!

Habe eben erst alle Übersetzungen angepasst. Ist etwas kompliziert.

Auch wenn Wordpress auf Deutsch eingestellt ist, müssen einige Übersetzungen für The Events Calendar von Hand eingetragen werden. Das läuft so bei vielen Plugins. Übersetzungsdateien von Wordpress können im Core, im Theme oder im Plugin versteckt sein. Und wenn du mit einem Child Theme arbeitest (was ich grundsätzliche für besser halte), müssen noch die entsprechenden Dateien im Child Theme überprüft werden. Aber das ist ein anderes Problem...

Die Sprachdateien liegen im Dateiformat .mo vor, die allerdings nicht direkt bearbeitet werden kann. Dazu braucht man die Vorlage .po. Veränderungen in der .po können in einem passenden Editor erledigt werden - und auf keinen Fall etwa in MS Word! Falls du mal etwas davon gehört hast, dass sich einzelne Elemente der Übersetzung unmittelbar korrigieren lassen: Stimmt, aber solch ein Klein-Klein über PHP ist unnötig.

Die Sprachdatei lässt sich z.B. im kostenlosen Programm Poedit korrigieren. Nach Installation von Poedit auf dem Rechner und Öffnen des Programms gibt es die Wahlmöglichkeit "Übersetzung bearbeiten". Anklicken und die passende .po laden. Vorgehensweise ansonsten von mir bereits beschrieben im Forum unter (recht weit unten):

Zitat

http://forum.wpde.org/konfiguration/…uebersetzt.html

Wenn du ohne Child Theme arbeitest, musst du damit leben, dass die Sprachdatei bei jeder Aktualisierung überschrieben werden kann! Dann also unbedingt Sicherungskopien aufheben!

Klingt alles kompliziert? Nein, ist es nicht! Du brauchst nur ein ftp-Programm und das leicht zu bedienende Poedit. Es ist allerdings etwas aufwändig, jeden Textschnipsel für eine Korrektur richtig zu treffen.

Und falls du es dir besonders leicht machen willst, stelle ich dir gerne meine frische .po und .mo von The Events Calendar zur Verfügung. Aber vielleicht gefällt dir nicht, dass ich event fast immer mit Termin und nicht mit Veranstaltung übersetzt habe. Guckst du hier:

Zitat

flohfernsehen.de

Da ich hier im Forum keine Datei anhängen kann, dann bitte Angabe von E-Mail-Adresse. Aber selber basteln führt zu persönlich passenderen Ergebnissen?

Einfache Lösung: Nicht den Link direkt in den Beitrag bzw. in die Playlist kopieren. Stattdessen irgendeinen Text mit dem Editor eintragen, der dann auf deiner Seite zu sehen sein soll, z.B. Video. Anschließend im Editor diesen Text mit einem Link belegen und dabei darauf achten, Häkchen zu setzen: Link in neuem Fenster/Tab öffnen.

In HTML sieht das dann so aus:

Zitat

<p><a href="

Externer Inhalt www.youtube.com

Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.

Inhalt einmalig anzeigen Alle externen Inhalte anzeigen

Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

" target="_blank">video</a></p>

Speichern, fertig!

In meinem Theme hat es so geklappt. Ich habe es aus Neugier getestet. Der direkte Einbau deines Links hat hingegen das Video sofort aktiviert, wie du es beschrieben hast. Ohnehin wäre die volle Angabe des Links nach meinem Geschmack nicht schön: Eine aussagekräftige Bezeichnung wirkt netter.

Oder vielleicht habe ich dein Problem falsch verstanden?

Noch Interesse an dem Thema? Da es nur um einen Link geht, ließe sich das Problem leicht über CSS lösen.

Vielen Dank für die schnelle Rückmeldung! Bringt leider nicht die gewünschte Wirkung...

Hätte mich auch gewundert, denn in PHP sollten nach meiner Kenntnis deine und meine Formulierung gleichwertig sein. Aber man hat natürlich schon Wunder bei der Programmierung erlebt... Ich bevorzuge meine Reihenfolge, denn es erscheint mir logisch, erst die Funktion zu definieren und anschließend die Wirkung add_action von dieser Funktion. Allerdings beachtet PHP diesen Zusammenhang nicht streng. Und die meisten bevorzugen wohl deine Vorgehensweise.

Jedenfalls staune ich noch immer, dass der direkte Weg ohne Kapselung in eine Funktion zum Ziel führt. Vielelicht bin ich mit solchen Spitzfindigkeiten falsch hier im Forum. Jedenfalls ist mir aufgefallen, dass sich die User vornehm zurückhalten, wenn es um Child Themes oder gar um konkreten Code in PHP geht.

Hingegen sorgen eher Fragen zu Plugins oder Design für Aufregung. Auch ich bin sehr an diesen Problemen interessiert, zumal ich nicht aus dem Development stamme und Wordpress erst jetzt erkunde. Allerdings ist es mir wichtig, meine Wordpress-Installationen sauber und nach aktuellen Regeln zu fahren. Ich bastele lieber stunden- oder sogar tagelang an meiner functions.php, als dass ich faule Plugins einbaue oder immer wieder meine Sprachdateien bei seltsamen Updates überschreiben lasse. Wenn ich alles wunschgemäß eingerichtet habe, würde mein System selbst im Dauerbetrieb reibungslos laufen, zumal ich mit disable_translation_updates.php automatische Updates der Übersetzungsdatei im Core verhindere.

Vielleicht hat ja noch jemand eine Idee, wie ich zu meiner gewünschten Funktion in der functions.php komme?

Das alles klingt danach, dass mehrere verstreute Sprachdateien genutzt werden und die Plugins eigene Sprachdateien zur Verfügung stellen - bei mir ist es ähnlich gewesen. Aber ich habe jeden Krümel aufgespürt und geändert: Mit dem Plugin String Locator von Clorith lassen sich nicht nur Codes finden, sondern auch sonstige Wörter bzw. Textelemente in nicht direkt über das Dashboard zugänglichen Dateien - also in JavaScript und eben in .po und .mo.

Wenn ich zum Beispiel den Begriff event suche, der nicht nur in meinem Plugin für den Terminkalender steckt, kann ich den gesamten Wordpress Core einschl. aller Installationen scannen. Oder ich beschränke mich z.B. auf ein einzelnes Plugin. Die Einträge in CSS oder PHP interessieren mich für eine Übersetzung nicht. Aber bei den .po und .mo weiß ich endlich, wo sich der verdammte Schnipsel versteckt.

Mit Poedit bearbeite ich die entsprechende .po. Dazu nutze ich Bearbeiten > Suchen aus dem Hauptmenü und finde selbst bislang von mir übersehene Stellen mit event - Häkchen bei Quellcode dabei nicht vergessen. Und manchmal kann der Suchbegriff in einer Variablen stecken, so dass ich ihn nicht direkt sehe. Wenn also nach dem ganzen Heckmeck die Änderung an der gewünschten Stelle im Browser nicht geschieht, muss ein benachbarter Begriff gescannt werden, um die Variablenzuordnung noch zu korrigieren.

Alle Stellen mit Poedit geändert? Dann speichern und Datei > MO-Datei herstellen; beim speichern die alte .mo-Version überschreiben. Nach dem Hochladen mit ftp wird sich beim Browser-Refresh zeigen, ob die gewünschte Stelle getroffen worden ist.

Beim Einsatz eines Child Themes ist darauf zu achten, dass die Änderung nicht in der Sprachdatei vom Parent Theme, sondern vom Child Theme erfolgt. Auch dabei kann einiges schief gehen...

http://www.flohfernsehen.de: Endlich habe ich verstanden, wie ich die Sprachdatei in mein Child Theme einbinden sollte. Nach Erstellung eines Ordners "languages" im Ordner meines Child Themes yoko-changes (basierend auf Theme yoko) habe ich die überarbeiteten Sprachdateien .mo (und .po als Sicherheitskopie) in dieses Verzeichnis "languages" gepackt. Dann habe ich eine neue Funktion in meiner functions.php vom Child Theme mit einem Hook erstellt:

function my_child_theme_setup() {  load_child_theme_textdomain('yoko', get_stylesheet_directory().'/languages');
} 
add_action( 'after_setup_theme', 'my_child_theme_setup' );

Sollte doch alles in Ordnung sein, nicht wahr? Ist es aber nicht! Nach wie vor wird die alte Sprachdatei vom Parent Theme genutzt!

Selbst Änderungen der Priorität von add_action (oder in Verzweiflung von load...) helfen nicht.

Jetzt passiert Voodoo: Es gibt eine Problemlösung, die ich allerdings lieber vermeiden möchte - durch Verzicht auf Kapselung in eine Funktion und stattdessen Direktausführung lässt sich die richtige Sprachdatei nutzen:

load_child_theme_textdomain('yoko', get_stylesheet_directory().'/languages');

Schon der Austausch von stylesheet gegen template würde das Ergebnis wieder zerstören. In functions.php vom Parent Theme wurde für diese Angelegenheit ebenfalls auf Def. einer Funktion verzichtet:

/**
 * Make theme available for translation
 * Translations can be filed in the /languages/ directory
 */
load_theme_textdomain( 'yoko', get_template_directory() . '/languages' );

Ich würde gerne hübsch sauber den nötigen Code in eine Funktion stecken, aber das scheint nicht zu klappen? Bereitet vielleicht after_setup_theme in meinem Theme diese Schwierigkeiten? Allerdings habe ich bereits andere Hooks wie init versucht: Nichts! Bisher läuft es nur mit der Direktausführung, also ohne Aufbau einer neuen Funktion.

Notfalls kann ich damit leben, aber vielleicht erkennt jemand meinen Denkfehler?

Mit Mühe habe ich ein Child Theme nach den aktuellen Vorgaben über functions.php gebastelt. Inzwischen läuft diese Konstruktion wunderbar für CSS und übernommene PHP-Dateien wie Header. Aber eine Nutzung vom Child Theme für JavaScript ist bislang nicht möglich.

Ich habe im Child-Ordner ein Verzeichnis js für die custom.js angelegt. In functions.php lautet der Code für CSS ud für JavaScript:

<?php
	function mein_js_laden() {
		wp_dequeue_script('parent-theme');
		wp_enqueue_script('handlerMeinesScripts', get_stylesheet_directory_uri() . '/js/custom.js', array('jquery')
/** Name des Scripts (benötigt man z.B. zum Entfernen, etc.); Ort der Script-Datei;
Liste der Scripts, welche von der Script-Datei benötigt werden - in diesem Falle das von Wordpress geladene jqeury
 *
 */    
		);
} 
	add_action('wp_enqueue_scripts', 'mein_js_laden');
?>
<?php
/**
 * Bei Umstellung von grün auf anderes Farbschema in functions.php muss in green_complete:css der Eintrag important für hover entfernt werden
 *
 * dann muss evtl. an gleicher Stelle in der dann benutzten CSS des Farbschemas important gesetzt werden; so kann (die in diesem Fall alte) green_complete.css auch bei Wechsel in functions.php stehen bleiben
 *
 * natürlich müsste dann noch Eintrag des neuen Farbschemas in functions.php erfolgen
 * ----------------------------------------------------------------------------
 */
 	function load_parent_style() {
 		wp_register_style('parent-theme', get_bloginfo('template_directory').'/style.css');
		wp_register_style('parent-theme', get_bloginfo('template_directory').'/css/color_scheme/green.css');
 		wp_enqueue_style('parent-theme');
 }
	add_action('wp_head','load_parent_style',0);
?>
<?php
	function enqueue_styles() {
		wp_enqueue_style( 'custom', get_stylesheet_directory_uri().'/green_complete.css', array(), 1.0, 'screen' );
		wp_enqueue_style( 'custom', get_stylesheet_directory_uri().'/style.css', array(), 1.0, 'screen' );
}
	add_action('wp_enqueue_scripts', 'enqueue_styles');
?>

Für i-transform habe ich eine Subnavi erstellt, die von diesem Theme nicht vorgesehen ist. Dem div-Container mit den Menü-Elementen habe ich die Klasse "extra-container" verpasst, weil die Hauptnavi die Klasse "nav-container" trägt. In JavaScript möchte ich erreichen, dass auch die Elemente von "extra-container" im mobilen toggle-Menü berücksichtigt werden. Die dafür nötige Änderung funktioniert im Parent Theme mit:

/* Side responsive menu	 */
	$('.menu-toggle').sidr({
      	name: 'sidr-left',
      	side: 'left',
		source: '.nav-container, .extra-container',
			onOpen: function() {
				$('.menu-toggle').animate({
					marginLeft: "260px"
				}, 200);
			},
			onClose: function() {
				$('.menu-toggle').animate({
					marginLeft: "0px"
				}, 200);
			}
	});

Wenn ich aber den etwas kürzeren Ursprungscode im Parent Theme belasse und diesen veränderten Code in meine custom.js eintrage, passiert leider nichts - obwohl custom.js in meinem Child Theme durch die Angaben in functions.php wohl auch erkannt wird. Jedenfalls zeigt der Quellcode die korrekten Daten. Trotzdem überlagert meine Modifizierung in custom.js nicht die entsprechende Stelle im Original von i-transform/js/functions.js - was ist bloß los?

Reihenfolge war schuld

Vielen Dank für die schnellen Rückmeldungen! Inzwischen habe ich den Fehler gefunden.

Die Verwaltung klappt besser, wenn ich function enqueue_styles() mit zwei anstatt mit einem kombinierten wp_enqueue_style gestalte. Dabei ist allerdings die richtige Reihenfolge unerlässlich, denn enqueue legt sie ja fest und baut eine Warteschlange auf.

Falls jemand interessiert ist - der funktionierende Code:

<?php
     function load_parent_style() {
         wp_register_style('parent-theme', get_bloginfo('template_directory').'/style.css');
        wp_register_style('parent-theme', get_bloginfo('template_directory').'/css/color_scheme/green.css');
         wp_enqueue_style('parent-theme');
 }
    add_action('wp_head','load_parent_style',0);
?>
<?php
    function enqueue_styles() {
        wp_enqueue_style( 'custom', get_stylesheet_directory_uri().'/green_complete.css', array(), 1.0, 'screen' );
        wp_enqueue_style( 'custom', get_stylesheet_directory_uri().'/style.css', array(), 1.0, 'screen' );
}
    add_action( 'wp_enqueue_scripts', 'enqueue_styles');
?>

Nach vielen vergeblichen Versuchen bin ich froh, dass meine Wordpress-Installation vom Child Theme zu i-transform jetzt vernünftig läuft. Die Einträge in der functions.php liefern allerdings nur für den Haupt-Style style.css die richtigen Ergebnisse. Das Theme i-transform bietet ein bequemes Farbschema, dessen CSS allerdings ein paar kleinere Erweiterungen nach meinem Geschmack benötigt.

Weil dieses Skript nicht allzu umfangreich ist, habe ich nicht nur die Änderungen, sondern den gesamten Inhalt von green.css in mein Child-Verzeichnis kopiert und nachträglich die Anpassungen eingetragen. Dieses Farbschema wird nicht erkannt, sondern nach wie vor wird das unvollständige Skript green.css gezogen (Überprüfung im Quellcode, und auffallende Änderung eine CSS-Eintrags wird nicht übernommen).

Weil zuvor der Haupt-Style hakte, habe ich einen extra Code zum vorherigen Ladens des Parent Themes eingetragen: Für die korrekte Darstellung benötige ich unbedingt style.css aus dem Parent Theme, das dann durch die Einträge in style.css vom Child Theme ergänzt oder korrigiert wird. Aber das Farbschema mit meiner neuen green_complete.css funktioniert dabei leider nicht. Hat jemand eine Idee, was ich als php-Legastheniker verbockt haben könnte?

In meiner functions.php:

<?php     add_action('wp_head','load_parent_style',0);         function load_parent_style() {     wp_register_style('parent-theme', get_bloginfo('template_directory').'/style.css');    wp_register_style('parent-theme', get_bloginfo('template_directory').'/css/color_scheme/green.css');     wp_enqueue_style('parent-theme'); }?><?php    function enqueue_styles() {        wp_enqueue_style( 'custom', get_stylesheet_directory_uri().'/green_complete.css', get_stylesheet_directory_uri().'/style.css', array(), 1.0, 'screen' );}    add_action( 'wp_enqueue_scripts', 'enqueue_styles');?>