Kategorien
Wochenbericht

Wochenbericht 2018.50

Vorletzte Runde dieses Jahr und dabei ist ein echtes Highlight vom Webrocker, welches interessante Diskussionen zum Thema Kunden, Bezahlung und Co aufgeworfen hat.

  1. KMUnverstand
  2. Simplify Your Vue Components with Computed Setters
  3. Design Thinking: Was ist das eigentlich?
  4. Bootstrap 3.4.0 released
  5. Visual Studio Code (Version 1.30) Released
  6. Wer ist krank, schwanger, tiefgläubig oder will fremdgehen? Etliche Android-Programme geben solche privaten Details an Facebook weiter, ohne ihre Nutzer darüber aufzuklären.

Was zum Lachen: kopfgesteuerte und fußgesteuerte while-Schleifen

Kategorien
Wochenbericht

Wochenbericht 2018.49

  1. How to use React with Symfony 4
  2. Kommentar: Ohne Edge steht nur noch Firefox gegen die Chromium-Dominanz
  3. It’s official, Chromium is coming to Microsoft Edge
  4. You may not need Axios
  5. WordPress 5.0 is here! – Und auch schon hier im Einsatz

Was zum Lachen: What counts as a bug?

Kategorien
Webentwicklung Werkzeuge

„To fix this issue you can simply rename your file to api2.php“

Ich bin ja auch Nutzer von InfiniteWP. Das ist eigentlich ein sehr gutes Tool zum Verwalten von mehreren WordPress-Instanzen.

Nun hatte ich in einem Kundenprojekt eine API entwickelt, die zur Authentifizierung ein WordPress mit einer Nutzerdatenbank verwendet. Dazu habe ich von einem externen Projekt die wp-load.php inkludiert. Das funktionierte auch eine zeitlang auch sehr gut, bis die Agentur, die die Seite betreut, ein paar Änderungen vornahm. Sie installierten unter anderem InfiniteWP. In der datei „api.php“ von InfiniteWP ist folgender Code:

if(basename($_SERVER['SCRIPT_FILENAME']) == "api.php"):
    exit;
endif;

Das Ziel dieses Codes ist relativ offensichtlich: Die Datei sollte nicht direkt geladen werden können. Blöd ist: Es wird nur auf den Dateinamen geprüft. Da meine externe Datei, auch api.php heisst, wird aber, sobald ich die wp-load.php include, das exit; ausgeführt.

Ich regte also an, vielleicht nicht nur den Filename zu überprüfen, sondern vielleicht auch den Pfad des aufgerufenen Scripts oder – wie unter WP auch nicht unüblich – auf eine gesetzte Konstante. Auf meine Anfrage beim Support bekam ich folgende Antwort:

Thanks for taking the time to reach out to us on your query. Your patience is greatly appreciated.

We are using api.php in our client plugin to use call back functions for our addons.
To fix this issue you can simply rename your file to api2.php

Are you experiencing any conflict issues with IWP client plugin and other plugins?
Please give us more information so that I can assist you accordingly.

Ich habe dann etwas möglicherweise etwas unhöflich reagiert und gefragt, wie sich das verhält, wenn der nächste dann das gleiche mit proxy.php und jemand anderes dann die index.php seines Plugins so schützt. Und dass ein HTTP Status 200 und eine weiße Seite in dem Fall auch nicht sinnvoll debugbar sind und dass mich das einige Tage Projektverzögerung gekostet hat und ziemlich beschissen ist. Zumal es in WordPress ja auch Beispiele gibt, wie es besser geht.

Erst darauf hin habe ich die Antwort bekommen, dass ein „scope of improvement on our end“ vorhanden sei. Da geben sich dann Codequalität und Servicequalität dann echt nichts.

Ich habe mal ein Beispiel geschickt, wie man das sinnvoller lösen kann. Mal sehen, wann ein Update dafür kommt.

Kategorien
Webentwicklung Werkzeuge

Creating a Professional WordPress Development Workflow With Vagrant

Creating a Professional WordPress Development Workflow With Vagrant

Kategorien
Code Webentwicklung

Performance steigern für WordPress Child-Themes: Alternative zu @import

Oft findet man beim Thema WordPress Child Themes den Hinweis, dass man die Parent-Theme-CSS-Datei im Childtheme dann mittels @import übernehmen soll, wie z.b. so:

/* Use @import, to borrow the style sheet from the Waipoua parent theme */
@import url('../waipoua/style.css');

Das ist zwar richtig und funktioniert, kann aber durchaus nachteilige Effekte auf das CSS-Rendering und Ladeperformance haben. Schließlich wird erst die Child-Theme-Datei geladen, die stößt den Parent-Download und dann muss das ganze lustig berechnet werden.

Einfacher ist es, wenn man die Parent-Style-Datei entweder komplett kopiert oder direkt im HTML einbindet.

Methode 1: Kopieren des Parent-Styles

Vorteil: Nur eine Style-Datei, nur ein Request, kein Style-Merging: Optimale Performance

Nachteil: Beim Theme-Update müssen Differenzen ggf. mühsam  per Hand übertragen werden.

Methode 2: Einbinden ins HTML statt per @import

Vorteil: Update-Kompatibel, nur geänderte Styles müssen in die Datei, Performance besser als bei @import

Nachteil: Perfomance ist schlechter als eine Kopie des Parents

Mein Senf: Methode 2 gewinnt

Aus meiner Sicht ist die Methode 2 besser geeignet, da hier der Wartungsaufwand bei Theme-Updates gegen 0 tendiert, genau wie bei @import. Aber wie funktioniert das?

Zuerst löscht man die @import-Zeile aus der style.css. Dann fügt man in die functions.php folgendes ein:

add_action('wp_enqueue_scripts', 'add_parent_css');
function add_parent_css() {
	wp_enqueue_style('waipoua_main', get_template_directory_uri() . '/style.css', false, '');
	wp_enqueue_style('waipoua_child', get_stylesheet_uri(), 'waipoua_main' );
}

Hier passiert folgendes: Mit get_template_directory_uri() bekommt man das Verzeichnis des Parent-Themes, während man mit get_stylesheet_uri() die Stylesheet-URL des aktiven (in diesem Fall des Child-) Themes bekommt.

Die Namen für die Stylesheets („waipoua_main“ und „waipoua_child“) sind in diesem Fall der Umgebung bei Develovers.de geschuldet, die könnt ihr nennen wie ihr wollt.

Schon meckern Perfomance-Tools evtl. nur noch die Einbindung mehrerer Stylesheets an, aber nicht mehr die Verwendung von @import.