3UU

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.

Patch files are great – merge requests on Github are better ??

Aufgrund Deiner Seite vermute ich mal, wie verstehen uns besser auf Deutsch. Grundsaetzlich bin ich ja ein Fan davon, spezielle Services auszulagern. So wie Du das bei Piwik ja auch machst. Beim Backend muessten wir uns dann aber was einfallen lassen, wie wir die “berechtigten” Domains igentifizieren. Da habe ich jetzt in Deinem Patch nichts gefunden. Und selber auch noch keine Idee. Grundsaetzlich alle Installationen fuer jeden nutzbar zu machen, halte ich aber fuer eine ganz schlechte Idee.

Ich sehe jetzt auch nicht so wirklich den Vorteil, den es allgemein fuer die Plugin-Nutzer haben koennte. Denn mit dem neuen Backend braucht es eh eine WP-Installation. Dann kann man auch gleich komplett auf den schnelleren Server umziehen ?? Oder ein Plugin fuer memcache/d nutzen. Das duerfte allemal schneller sein als der Request zu einem weiteren Server. Und wenn der zusaetzlich Request nicht stoert, koennte man auch schlicht den Webserevr nen 302er oder 301er Header fuers Backend senden lassen.

Hm, viele wenn und aber. Darueber sollten wir imho erstmal Klarheit bekommen, bevor wir Deinen Patch umsetzen.

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.

Funktionierten alles Services nicht oder nur Flattr? Das neue Backend ist eigentlich sehr robust. Oder steht das Timeout nur noch “historisch” im Betreff? Flattr scheint leider oefter mal voellig unmotivierte Aussetzer zu haben. Ein paar Minuten spaeter geht es dann wieder. Konnte das bei mir zumindest so beobachten. Die anderen Services sollte das natuerlich nicht beeinflussen.

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 ist jetzt mit dem neuen Backend online. Probier es doch bitte mal.

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

Version 3.1 hat jetzt ein voellig neues Backend. Probierst Du es bitte mal.

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.

There was a commit at Github bei “hirasso” that will fix this problem. Code looks well but I have not tested it. However we this functionality will be part of the next release.

Hast Du mal versucht, die “https://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.

What version of the Plugin do u use? I foun d the CSS and font files are right. But the admin menu should show “Add the Shariff buttons after all:” and then “Posts (blog page)”.

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

Habe gerade 2.4.3 mit JPs Aenderungen released. Gehe mal davon aus, es ist damit geloest und close den Report. Falls nicht, mach bitte nochmal einen neuen auf, damit wir es nicht uebersehen.

This suggestion is funny! Okay – sorry – only from programers point of view. WP_DEBUG is a so called constant. You can not change it later in a program. If you do it – you will get an error ??

I have released 2.4.0 some minutes ago. It do no longer need the constant.