Lösungen zum Erzeugen von dynamischem Javascript / CSS

Angenommen, Sie müssen JavaScript oder CSS-Code generieren, der vom aktuellen Kontext abhängt.

Zum Beispiel haben Sie ein Formular auf der Homepage, das eine Ajax-Anfrage beim Senden austriggers, und ein anderes Formular auf der einzelnen Seite. Oder im Fall von CSS möchten Sie ein Design erstellen, das es Benutzern ermöglicht, ihr eigenes Layout zu erstellen, colors zu ändern usw.

Lösungen, die ich bisher gesehen habe:

  1. Fügen Sie den Code in den Kopfbereich des Dokuments ein (oder im Falle von JS am Ende)

  2. Führen Sie eine spezielle Anfrage aus, die den Code ausgibt, beispielsweise site.com?get_assets . Das ist langsam, weil WP zweimal geladen wird.

  3. Speichern Sie es für eine bestimmte Zeit in temporären Dateien und laden Sie es von dort. Nicht sehr zuverlässig für öffentliche Themen oder Plugins.

  4. Javascript nur – machen Sie es statisch, indem Sie es in eine normale Datei einfügen, die jedes Mal geladen wird. In diesem Fall müssten Sie Ihren Code für jede Situation verwenden

Kennst du andere? Welchen Weg würdest du gehen?

Solutions Collecting From Web of "Lösungen zum Erzeugen von dynamischem Javascript / CSS"

Eine zusätzliche Option, abhängig von der Art der Parameter, die Sie übergeben müssen. Sagen wir es (2a). Sie können auch PHP-Skripte erstellen, die dynamisch generierten text/css oder text/javascript anstelle von text/html ausgeben und ihnen die benötigten Daten über GET-Parameter zur Verfügung stellen, anstatt WordPress zu laden. Dies funktioniert natürlich nur, wenn Sie eine relativ kleine Anzahl relativ kompakter Parameter eingeben müssen. Wenn Sie zum Beispiel sagen, dass Sie nur die URL eines Posts oder das Verzeichnis einer Datei oder Ähnliches eingeben müssen, können Sie Folgendes tun:

In der header.php:

   

In fancy-js.php:

  < ?php header("Content-type: text/javascript"); ?> foo = < ?php print json_encode($_GET['foo']); ?>; url = < ?php print json_encode($_GET['url']); ?>; 

etc.

Dies ermöglicht Ihnen jedoch nur den Zugriff auf die Daten, die direkt in den GET-Parametern übergeben werden. und es wird nur funktionieren, wenn die Anzahl der Dinge, die Sie übergeben müssen, relativ klein ist, und die Darstellung dieser Dinge relativ kompakt ist. (Im Allgemeinen eine Handvoll von String- oder numerischen Werten – ein Benutzername, sagen wir, oder ein Verzeichnis; keine Liste aller letzten Beiträge eines Benutzers oder so ähnlich.)

Was für eine dieser Möglichkeiten ist die beste – ich weiß es nicht; Das hängt von Ihrem Anwendungsfall ab. Option (1) hat den Vorteil, einfach zu sein und Ihnen den Zugriff auf alle WordPress-Daten zu ermöglichen, die Sie möglicherweise benötigen, ohne dass WordPress zweimal geladen wird. Es ist fast sicher, was Sie tun sollten, wenn Sie keinen starken Grund haben, dies nicht zu tun (zB aufgrund der Größe des Stylesheets oder Skripts, die Sie verwenden müssen).

Wenn die Größe groß genug ist, um ein Problem hinsichtlich des Gewichts Ihrer einen Seite zu verursachen, können Sie (2) oder (2a) ausprobieren.

Oder – das ist wahrscheinlich die bessere Idee – Sie können versuchen, die Teile des Skripts oder des Stylesheets voneinander zu trennen, die tatsächlich die dynamischen Daten aus den Teilen verwenden, die statisch angegeben werden können. Ssay Sie haben ein Stylesheet, das ein Verzeichnis aus WordPress übergeben werden muss, um einen Hintergrundparameter für das # my-fancy-Element festzulegen. Sie könnten all dies in das Kopfelement einfügen:

   

Aber warum sollten Sie das tun? Es gibt hier nur eine Zeile, die von Daten aus WordPress abhängt. Besser nur die Zeilen aufteilen, die von WordPress abhängen:

   

Setze alles andere in ein statisches Stylesheet, das du mit einem Standard-Link-Element (style.css oder was auch immer) einlädst:

  #my-fancy-element { /* background-image provided dynamically */ padding: 20px; margin: 20px; font-weight: bold; text-transform: uppercase; font-size: 12pt; /* ... KB and KB of additional styles ... */ } #another-fancy-element { /* ... KB and KB of additional styles ... */ } /* ... KB and KB of additional styles ... */ 

Und lass die Kaskade die Arbeit machen.

Das gleiche gilt für JavaScript: anstatt dies zu tun:

   

Setze stattdessen so etwas in das Kopfelement:

   

Lassen Sie dann den Rest in eine statische JavaScript-Datei fallen und schreiben Sie die functionen my_huge_function () und my_other_function () neu, um die Globals WordPressPostData.url und WordPressPostData.author zu verwenden.

40K von CSS oder 40K von JS können fast immer in <1K aufgeteilt werden, das tatsächlich von dynamischen Daten abhängt, und der Rest kann in einer statischen externen Datei angegeben und dann unter Verwendung der Kaskade (für CSS) oder global zugänglich neu kombiniert werden Variablen (Globals, DOM-Elemente oder was auch immer anderes Cubby-Loch Sie bevorzugen, für JS).

Der dynamische CSS-Fall ist ziemlich einfach.

Erstellen Sie einfach eine function, die die dynamischen CSS-Definitionen innerhalb von

-Tags wp_print_styles , und haken Sie diese function dann in wp_print_styles . z.B

 < ?php function mytheme_dynamic_css() { $options = get_option( 'mytheme_options' ); ?>  < ?php } add_action( 'wp_print_styles', 'mytheme_dynamic_css' ); ?> 

Oder nehmen wir an, Sie haben vorkonfigurierte Farbschemata; Sie können das entsprechende Stylesheet gemäß der aktuellen Benutzereinstellung in die Warteschlange stellen:

 < ?php function mytheme_enqueue_colorscheme_stylesheet() { $options = get_option( 'mytheme_options' ); $color_scheme = $options['color_scheme']; wp_enqueue_style( $colorscheme, get_template_directory_uri() . '/css/' . $color_scheme . '.css' ); } add_action( 'wp_enqueue_scripts', 'mytheme_enqueue_colorscheme_stylesheet' ); ?> 

Beachten Sie, dass sich die function in diesem Fall in wp_enqueue_scripts , da WordPress keinen wp_enqueue_styles .

Das dachte ich schon eine Weile. Deine Frage bringt mich dazu zurück zu kommen. Ich bin mir nicht sicher, ob es eine gute Idee ist oder nicht, daher hätte ich gerne Experten dazu.

Was, wenn ich die Javascript / CSS-Datei über PHP schreibe, wenn Admin die Daten speichert. Es wird ein einmaliger Schreibvorgang durchgeführt, bis der Benutzer das Layout erneut ändert (was der Benutzer möglicherweise nicht oft macht). Auf diese Weise greifen wir nur einmal auf die database für die Benutzereinstellungen zu, wenn Benutzer Daten speichern.

Nach dem Schreiben der Datei wird es eine reguläre Javascript / CSS-Datei sein, so dass wir nicht jedes Mal die database aufrufen müssen, wenn das Thema geladen wird.

Eine Frage, die beantwortet werden muss: Was passiert, wenn ein Besucher versucht, auf die Seite zuzugreifen, wenn er die Datei schreibt?

Lass mich wissen was du denkst.

Für kleine Teile von Skripten, die Sie vielleicht nicht in eine separate Datei aufnehmen möchten, weil sie beispielsweise dynamisch generiert werden, bietet WordPress 4.5 und weitere wp_add_inline_script . Diese function speichert das Skript grundsätzlich in einem anderen Skript. Nehmen wir beispielsweise an, Sie entwickeln ein Thema und möchten, dass Ihr Kunde seine eigenen Skripts (wie Google Analytics oder AddThis) über die Optionen-Seite einfügen kann. Beispiel .

Für Styles gibt es wp_add_inline_style , was im Grunde gleich funktioniert. Sie würden es zum Beispiel verwenden, um alle Ihre Customizer-Mods zu durchlaufen und sie in einer Zeichenkette namens $all_mods , die Sie dann so zu Ihrem Haupt-Stylesheet hinzufügen würden:

 if (!empty($all_mods)) wp_add_inline_style ('main-style', $all_mods); 

Erstellen Sie eine dynamische JS.php-Datei und füttern Sie wichtige query_vars. Diese Variablen in $_GET helfen der Datei beim Ermitteln des Kontexts und darin können Sie readfile() für zukünftige Anfragen zwischenspeichern und verwenden … alles tun.

wp-load.php Sie nur sicher, dass die Datei vor allem anderen die wp-load.php lädt, damit Sie Zugriff auf WP-functionen haben. Verwende den relativen Pfad zum aktuellen Ordner (dirname(__FILE__)) oder (dirname(__FILE__)) einfach absteigend in der Ordnerstruktur, um wp-load.php unabhängig von der Platzierung des Plugins zu finden.

Code, um wp-load.php von überall zu suchen

 // Ensure single declaration of function! if(!function_exists('wp_locate_loader')): /** * Locates wp-load.php looking backwards on the directory structure. * It start from this file's folder. * Returns NULL on failure or wp-load.php path if found. * * @author EarnestoDev * @return string|null */ function wp_locate_loader(){ $increments = preg_split('~[\\\\/]+~', dirname(__FILE__)); $increments_paths = array(); foreach($increments as $increments_offset => $increments_slice){ $increments_chunk = array_slice($increments, 0, $increments_offset + 1); $increments_paths[] = implode(DIRECTORY_SEPARATOR, $increments_chunk); } $increments_paths = array_reverse($increments_paths); foreach($increments_paths as $increments_path){ if(is_file($wp_load = $increments_path.DIRECTORY_SEPARATOR.'wp-load.php')){ return $wp_load; } } return null; } endif; // Now try to load wp-load.php and pull it in $mt = microtime(true); if(!is_file($wp_loader = wp_locate_loader())){ header("{$_SERVER['SERVER_PROTOCOL']} 403 Forbidden"); header("Status: 403 Forbidden"); echo 'Access denied!'; // Or whatever die; } require_once($wp_loader); // Pull it in unset($wp_loader); // Cleanup variables 

Prost, Scribu!

PS : Für komplizierte Strukturen, in denen Ordner nicht der normalen WP-Dekrement-Struktur folgen, können Eltern-Plugins Informationen mit direkt zugänglichen Dateien teilen. Ein Eltern-Plugin, das mit einer dynamischen PHP-Datei realpath() , die CSS / JS rendert, kann den realpath() der wp-load.php und die Standalone-Datei in eine Datei schreiben. Dies wäre ein Problem für 0,1% der WP-Benutzer. Ich denke, dass diejenigen, die Ordner verschieben und nicht der normalen Struktur folgen, wissen, was sie tun und wahrscheinlich PIMP-Plugins, die wp-load.php direkt laden wp-load.php .