3UU

Okay, umso laenger ich drueber gruebel, desto charmanter finde ich die Idee mit einem externen Backend-Server. Vor allem, weil ich auch soein paar “Experten” kenne, die mit Updates bei den Plugins gern mal schlampen 😉 Was mich noch stoert:

1.) ist die potenzielle Trennung von JS und Backend im Admin-Bereich macht fuer mich keinen Sinn. Vor allem mit Blick auf durchaus sinnvolle Browser-Features wie sameorigin. Zwei Eingaben sind da imho nur ne ueble Fehlerquelle.

2.) die Eingabe eines Protokolls ist problematisch. Wenn jemand “http://” reinhaut auf einer https-Seite, gibt es auch noch unschoene Warnungen. Daher wuerde ich es lieber mit “example.com/shariff-path” machen und “//” davor sowie “/backend/index.php beziehungsweise /shariff.js” dahinter setzen.

3.) auch der externe Server sollte sich ohne haendische Anpassungen updaten lassen. Also muessen wir die “erlaubten Domains” irgendwo hinterlegen. Eine zusaetzlich Option im Admin-Menue finde ich mit Blick auf all die Leute, die es einfach nur nutzen wollen, irgendwie doof. Ich waere dafuer, dass wir in bewaehrter Weise erstmal wieder mit einem Array in der wp-config.php starten. Das Backend liest die neuerdings ja eh immer aus. Und: Wer einen zentralen Backendserver fuer seine Installationen betreiben will, sollte auch in der Lage sein, nen Array da reinzuschreiben.

Meinungen? JP?

Es dauerte in der Tat auch bei meinen Testsystem etwa 20 % laenger. Aber dafuer laesst es sich jetzt auch gemeinsam mit WP tunen. Ganz zu schweigen den den vielen Problemen, die das alte Zend-Framework sonst je nach Server so machte… Nah und wenn Du tunen moechtest, probier doch mal Plugins wie “MemcacheD Is Your Friend”. Werkelt bei mir und ist innerhalb der TTL gut zehn mal schneller als der alte Cache. Aber das ist nen anderes Thema, weshalb ich das hier erstmal auf resolved setze.

Das hat offenbar was mit Deinem Cache zu tun. Probier mal, ob es klappt, wenn Du Cachify deaktivierst. Irgendwas wirft naemlich die Header des Backends raus und schreibt eigene. Witziergeweise liefert es dann einen 404er HTTP-Fehler, liefert den Content vom Backend dnn aber doch aus. Also irgendwas ist da ganz kaputt bei Deiner Konfiguration oder dem Plugin.

Hm, waere auch mal spannend zu erfahren, was passiert, wenn Du in der /wp-content/shariff/backend/index.php die ersten 5 Zeilen, welche mit “Header( ” anfangen, mit einem vorangestellt # auskommentierst. Also

#header( "Expires: Sat, 24 Jan 1970 04:10:00 GMT" ); // date from the past
#header( "Last-Modified: " . gmdate("D, d M Y H:i:s" ) . " GMT" ); // always changed
#header( "Cache-Control: no-store, no-cache, must-revalidate" );
#header( "Cache-Control: post-check=0, pre-check=0", false ); // just for MSIE 5
#header( "Pragma: no-cache" );

Die Header-Zeile mit dem JSON aber bitte drin lassen 😉 Dein Server liefert als Expire naemlich immer “Wed, 11 Jan 1984 05:00:00 GMT”. Daher vermute ich mal, das Plugin kommt mit Cache-Headern nicht klar.

Version 3.1 with the new backend is online now. This has not the final solution because the config file has to get an update with every new version. However if this way works for you I have an idea how we can fix the problem and make a permanent solution.

Version 3.1 has the new backend now. Please give it a try.

Hallo ralfralfralf, das frage ich mich auch immer wieder 🙁 Aber da musst Du Dich bitte an https://github.com/heiseonline/shariff/issues wenden. Unser Plugin ist – wie der Name schon sagt – lediglich ein Wrapper fuer WordPress. Wir haben zwei Ausnahmen gemacht: Bei den Fonts, weil Shariff im Original da Fonts ueber ein CDN Dritter zieht, was datenschutztechnisch echt bedenklich ist. Die “selbst gehostete” Variante wuerde aber unnoetig Traffic erzeugen, weshalb JP da dankenswerter Weise einen minimale Variante fuers Plugin gebaut. Und die zweite bei der Mailfunktionalitaet, weil die sehr spezifisch auf WordPress zugeschnitten werden muesste. Mehr moechte ich da aber auch nicht am Original “rumbasteln”, denn sonst berauben wir uns potenziell der Moeglichkeit von Updates. Insofern schliesse ich Deinen Request hier mal und hoffe, Du hast Verstaendnis dafuer.

Hast Du mal versucht, die “http://www.XXX.de” direkt von der Console aus aufzurufen? Und wenn das klappt, auch als der User, unter dem Dein Webserver werkelt? Der 403er sieht mir eher so aus, als ob Dein Server nicht “surfen” darf. Vielleicht auch mal beim Hostmaster nachfragen, ob dafuer vielleicht ein Proxy notwendig ist.

I also think to use suggestion of JP would be the best solution. Therefor this option was implemented 😉