3UU

The reason is easy: We have done some changes at the code that need an adjustment at the language files too. Therefor I have send you an email on 2015-06-09 and ask for help but do not get an answer ?? The problem is that I do not understand italian language. However I have updated version 2.3.4 now with Italian words the best way I could based on your old translations. I hope it will works well ??

The backend will not work properly if debug is on. This is not our fault. The original backend was not developed with WP in mind. And there are many good reasons for us not to change the original code. At least not within the wrapper plugin. Therefor we set WP debug to off because this will avoid errors at the frontend. The frontend view of the backend ?? But we need to include the wp-config for dynamic setup of the backend. The problem is that a CONSTANT should be constant. If do you have set WP_DEBUG too it will end up with this error in your logfiles… But counter will work also if somebody has set WP_DEBUG on. I think this is the best way the plugin will work with common WP installations.

Not nice – I know ?? On the other hand at a production system all error reporting, WP_DEBUG and so on should allways be disabled. This is the default of WP_DEBUG too. So usually there is no need to set this constant in wp-config. Therefor I do not want change this in the backend of the Shariff plugin. However if at any time the developers of the original backend code will clean up I would be more than happy to remove this WP constant from the the backend wrapper.

1) is a bug with the new designed mail form. Will be fixed with the next update on wordpress and is fixed on github.

2) I do not think that it is a good idea to get a BCC of an email that somebody send to somebody else. Under some conditions this could be a criminal offense! At least in Germany. So I do not want add this function. However if do you really want/need a copy of any email send by your server and do you use postfix as MTA please have a look at the config option always_bcc and sender_bcc_maps.

3) Captcha are a plague ?? I like the teergrube that we have already in the plugin. I think this is a better way to prevent abuse. However perhaps we will add a captcha option in the future too.

Version 2.2.2 behebt das “Problem”.

Ganz so schlimm ist es aber gar nicht. Das Plugin hat von Anfang an einen “leaked bucket” ( https://de.wikipedia.org/wiki/Leaky-Bucket-Algorithmus ) eingebaut. Das macht es fuer Spamer uninteressant und verhindert durch die Begrenzung auch, dass Dein Server geblacklistet wird. Grenzwert ist nen Erfahrungswert aus aus aktuell gut 25 Mio Emails, die ich so jaehrlich ueber meine Systeme versende ?? Aber Du hast Recht, dass ein clever gesteuerter Angriff per DDoS diesen Grenzwert umgehen kennte. Auch wenn der Aufwand fuer einen Spamer es sicher uninteressant machen wuerde. Aber man weiss ja nie, ob nicht doch mal einer drunter ist, der nicht wirtschaftlich denken kann. Aber sogar dann wuerden natuerlich die Limits Deines Mailservers zuschlagen. Falls die nicht gesetzt sind und/oder Du sie nicht setzen kannst, bringt das Plugin jetzt nun nen Blocker mit, dass die Formular-Funktionalitaet nur verfuegbar macht, wenn diese allgemein im Admin-Menu gesetzt sein muss.

Schoen, wenn es jetzt klappt ??

Ja, das sieht sehr nach nem selbst gepachten PHP aus. Und domainFACTORY is ja auch nicht ganz so klein. Gut moeglich, dass die dort eine Langzeit-Distro drauf haben und vielleicht sogar selber fleissig patchen. Bloed nur, wenn dann einige Funktionen von PHP nicht aktuell sind. Nuja, jetzt klappt es ja. Trotzdem schon was peinlich, wenn es 5 Jahre hinter der Entwicklung her hinkt. Vor allem, weil 5.2 offiziell ja nicht mehr supported ist. Damit wird es nicht nur schiewrig, bei Sicherheitsluecken schnell Loesungen anzubieten. Du bist halt auch in der Auswahl Deiner Webanwendungen ziemlich eingeschrankt.

BTW: Funktionieren bei Dir eigentlich die Counter? Die brauchen ja mindestens nen 5.4er PHP. Nur so aus Interesse. Nen Backport dafuer kann ich Dir leider nicht machen bzw. waere echt zu aufwaendig. Aber vielleicht hat Dein Hoster ja was “gezaubert” und es klappt trotzdem.

Aua, aua, aua, die ist von Januar 2011 !!! Alles vor 5.4 ist imho inzwischen unsupported. Hoffen wir mal fuer Dich, dass es von einer stabil gepflegten Distribution ist.

So, ich habe den Code so umgestrickt, teste mal bitte mit version 2.1.2

Ich vermute jetzt mal, dass Du bei Deinem Paket dort keine eigenen PHP-Dateien hochladen kannst. Sonst muesstest Du nur

<?PHP phpinfo(); ?>

in eine Datei mit der Endung php schreiben. Achtung, loeschen anschliessend nicht vergessen, denn das verraet auch potenziellen Angreifern ne Menge ueber das System. Dir hilft aber vielleicht auch ein Plugin wie “WordPress phpinfo”. Ist zwar schon lange nicht gepflegt. Aber an soeinem Einzeiler kann man ansich auch nicht viel warten ??

Hallo,

argl, da scheint mal wieder eine PHP-Version nicht mit verkuerzten Schreibweisen klar zu kommen ?? Ich habe die Stelle jetzt mal was umgeschrieben und als Version 2.1.1 commited. Probier bitte mal damit.

Auf meinen Test-Installationen lief es. Nen Parse-Error haette ich jedenfalls bemerkt ?? Lass mich doch bitte mal wissen, welche PHP Version Du einsetzt. Ob auf L/W/XAMP und was bei Dir phpinfo() zu short tags sagt.

gruss
ritze

Das Problem ist nur, dass WP gewisse Schnittstellen bietet, an die sich Leute halten sollte, damit es keine Probleme mit anderen Erweiterungen gibt. Egal ob nun Plugin, Theme oder schlimmstenfalls sogar hart reingecodet. Genau dafuer gibt es nunmal den WordPress Codex. Bei Shariff haben wir uns alle nur erdenkliche Muehe gegeben, uns strickt dran zu halten. Das betrifft nicht nur jQuery. Und auch schon einiges an Workarounds gemacht, um auch mit schlampig gecodeten Plugins und/oder Themes noch vernuenftige Ergebnisse zu bekommen. Ganz zu schweigen davon, dass Shariff (vor allem im Backend) eigentlich so gar nicht innerhalb von WP nutzbar ist… Das ist wirklich nen riesen Projekt geworden. Da ist man dann schonmal was sauer, wenn das Ergebnis als “empfindlich” bezeichnet wird. Hach, vielleicht reagiere ich einfach nur was “empfindlich” ?? Alles gut. Wollte es nur mal angemerkt haben.

Nah dann aber mal bitte bei den Autoren der anderen Plugins beschweren. Shariff Wrapper bindet jQuery so ein wie es in WP sein sollte.

Probier bitte jetzt mal mit der Version 1.9.9

Grundsaetzlich ist erstmal richtig, dass es keine spuerbare Auswirkungen auf die Ladezeit hat, weil es per Ajax nachgeladen wird.

Das Backend initialisiert aber einen ganz geringen Teil der Funktionalitaet von WP. Das ist einfach notwendig, damit nicht jeder haendisch die Konfiguration an seine Seite anpassen muss. Wer es trotzdem will, kann natuerlich einfach die index-Datei entsprechend anpassen. Daher haben WP-eigene Caches fast keine Chance einzugreifen. Macht ja auch wenig Sinn bei einem Tool, das selber “cachet”.

Serverseitige Systeme wie mod_pagespeed oder vorgeschaltete reverse Proxys halten sich normalerweise an die entsprechenden HTTP-Header, um ihren Cache zu fuellen. Da hat der Wrapper jetzt eine ganze Ladung Header dazu bekommen, die in den verbreiteten Cache-Systemen wie auch Browsern das Zwischenspeichern verhindern sollten. Ob die sich dran halten, laesst sich natuerlich nicht beeinflussen. Die geaengigste Massnahme, sie dazu zu zwingen, ist eine Auslieferung der Seite per https-Verbindung. Das liegt aber dann in der Verantwortung des Hostmasters und laesst sich durch WP oder ein Plugin nicht beeinflussen.

Und sogar wenn es ueber eine verschluesselte Verbindung laeuft, ist nicht gesagt, dass nicht doch ein Proxy dazwischen haengt, der entschluesselt -> cacht -> verschluesselt -> ausliefert. Das ist nicht mal zwangslaeufig was Kriminelles, sondern in einigen Firmen-Netzen mit besonders hohen Sicherheitsanforderungen sogar normal. Aber dann trotzdem weit ausserhalb der Verantwortung eines WP-Plugins ??

Und fuer Leute, die Wissen, was sie tun, gibt es die Konstanten

define("SHARIFF_BACKEND_TMPDIR","/www/example.com/htdocs/tmp");
define("SHARIFF_BACKEND_TTL","88");

fuer die wp-config.php

Mit der ersten laesst sich das TMP-Dir setzen, welches vom Backend genutzt wird. Mit der zweiten laesst sich die TTL zum Beispiel auf 88 Sekunden setzen. Beide werden auch den Spung auf die naechste groessere Version des Plugins ueberstehen. Nur SHARIFF_ALL_POSTS fliegt raus, weil die inzwischen besser im Admin-Menu abgebildet wird. Gute Gelegenheit, die Anpassung gleich mal zu erledigen ??

Das wir die TTL-Option auch im Admin-Menue einbauen, sehe ich ebenfalls nicht. Es ist einfach zu schnell ohne Verstand dort angeklickt. Wer dann Debuggen will, muss eh aufs Filesystem schauen… Also ist es als Konstante imho besser aufgehoben.

BTW: Wie es geht, steht uebrigens seit Version 1.3.0 in der FAQ ??

1.9.4 ist online. Sorry fuers lange Wartebn. War heute im “Kommunion-Stress” mitb der Familie.

Jepp. Sorry, das war diesmal nen maechtiger Umbau und da sind mir leider ein paar Sachen beim Testen “durchgegangen”.

Ah, okay, verstehe. Danke fuers Feedback!