Change #206

Change #130: Umstellung OC 1.0 -> OC 2.0 fertigstellen (lib->lib2)

log.php auf Codeversion 2 umstellen

Added by bohrsty about 6 years ago. Updated almost 6 years ago.

Status:erledigt% Done:

100%

Priority name:2 mittel
Assignee:bohrsty
Target version:Version 9
Ticket Referenz: Kategorien:logs system

Description

log.php auf Codeversion 2 umstellen


Related issues

Related to OC Entwicklung - Feature #217: Rückfrage bei Massen-Nachlogs erledigt
Blocks OC Entwicklung - Change #205: Beim Loggen letztes Logdatum vorschlagen erledigt

Associated revisions

Revision 2fb28300
Added by bohrsty almost 6 years ago

migrated code into lib2, put parts in existing classes, migrated template and included external parts into template, some bugfixes, updates #206

Revision c6fa97b7
Added by bohrsty almost 6 years ago

fixed mentioned bugs, updates #206

Revision bd33e67c
Added by bohrsty almost 6 years ago

added masslog warning from following, updates #217, updates #206

Revision c95c4e97
Added by bohrsty almost 6 years ago

bugfixes (cachelink translatable, logtype via GET, permission check for
teamcomment), updates #206, updates #241

Revision 32eeaae1
Added by bohrsty almost 6 years ago

removed message for duplicate log (ocprop), corrected tinymce-config,
updates #206

Revision 1fa15a09
Added by following almost 6 years ago

fixed duplicate log ignoring; updated HTML-Purifier license info
updates #206

History

#1 Updated by bohrsty about 6 years ago

  • % Done changed from 0 to 50

- code migriert und einige teile sinnvoll ausgelagert
- template migriert und teile aus dem code ins template uebernommen
- auf aktuellen master aufgesetzt (mergekonflikte angepasst)
- erste tests und bugfixes lokal

#2 Updated by bohrsty about 6 years ago

ich habe die "neue" log.php auf die version 4.5.0 des HTMLPurifiers aufgesetzt mit einer separaten oc-klasse um ihn zu konfigurieren und habe ihn in die lib2 verfrachtet... (daher auch die grosse zahl an neuen und veraenderten dateien)

einige teile des codes habe ich in existierende externe klassen ausgelagert, wenn es passte (user, cache, cachelog...)

#3 Updated by following almost 6 years ago

Review cache.class.php:
  • logTypeAllowed() verwendet noch die obsolete Tabelle cache_logtype. Stattdessen muss die Funktion logtype_ok() aus logtypes.inc.php verwendet werden
  • bei updateCacheStatus() sind die Einrückungen des SQL-Statements durcheinandergeraten
  • getUserLogTypes() hat einen Parameter $userId, der nicht verwendet wird.
  • logTypeAllowed(), getUserLogTypes() und teamcommentAllowed() sollten jeweils noch einen zusätzlichen Parameter $oldLogType haben - das ist der Typ eines editierten Logs und wird für die Portierung von editlog.php gebraucht: Man kann beim Editieren eines Logs den Logtyp immer beibehalten, auch wenn man diesen Typ nicht mehr neu loggen darf. Das ist z.Zt. für Admin-Logs beim Bearbeiten von Cachemeldungen relevant. Kann per Default = 0 gesetzt werden.
Review cachelog.class.php:
  • Vorschlag: in createNewFromCache() auch gleich die NodeID setzen, da diese Funktion ohnehin nur für lokal erzeugte Logs verwendbar ist.
Review log.php
  • logTypeAllowed() wird mit Parameter null aufgerufen, wenn $_POST['logtype'] nicht gesetzt ist. Erstaunlich, dass das bei dir funktioniert. :-)
  • Der Parameter 'rating' wird nicht validiert. Per direkten Aufruf von log.php?cacheid=nnn&rating=1&... kann man Ratings jenseits seiner Rating-Quota und Ratings ohne Fund erzeugen.
  • Die Template-Variable 'octeamcomment' wird anscheinend bei Admin-Logs immer auf true gesetzt. Das sollte aber nur passieren, wenn der Cache gesperrt (Status 6 oder 7) bzw. das Loggen für Nichtadmins verboten ist und es kein eigener Cache ist.
  • In Zeile 53 wird per
    $error['logAllowed'] = ($cache->allowLog() || $useradmin || $cache->getStatus() != 5);

    das Loggen aller veröffentlichten Caches erlaubt, auch wenn sie gesperrt sind (status = 6 oder 7).
  • Benennung und Inhalt der Variable $error widersprechen sich - $error['logPw']=true suggeriert z.B. "falsches Logpasswort". Ich denke $validate wäre passend - es geht um die Validierung von Eingabewerten.
Konfiguration:
  • Eintrag $opt['html_purifier']['cache_path'] in settings-dist.inc.php fehlt - sollte wohl cache2/html_purifier sein?

Test:
Nachdem ich den Konfigurationseintrag für $opt['html_purifier']['cache_path'] in meiner settings.inc.php gesetzt habe, kommt beim Versuch einen Cache zu loggen Folgendes:

Warning: chmod() [function.chmod]: Die Operation ist nicht erlaubt in /mnt/server-3.0/htdocs/lib2/HTMLPurifier/library/HTMLPurifier/DefinitionCache/Serializer.php on line 112 > 1

... und sonst nichts mehr. In config2/html_purifier wurde irgendwas angelegt, also das Verzeichnis ist beschreibbar.

#4 Updated by following almost 6 years ago

  • Status changed from offen to in Arbeit 20%

#5 Updated by following almost 6 years ago

Da eben wieder eine Massen-Nachlogaktion lief, habe ich auf die Schnelle und provisorisch die #217 eingebaut. Hab es in einem privaten Branch gemacht und den direkt auf das Produktivsystem gemerged, damit du keine Konflikte bekommst, aber das müsste dann auch noch in die neue log.php: https://github.com/following5/oc-server3/commits/217_masslog_warning

Weitere Diskussion dazu: http://forum.opencaching-network.org/index.php?topic=3000.msg40208#msg40208

#6 Updated by bohrsty almost 6 years ago

following schrieb:

Da eben wieder eine Massen-Nachlogaktion lief, habe ich auf die Schnelle und provisorisch die #217 eingebaut. Hab es in einem privaten Branch gemacht und den direkt auf das Produktivsystem gemerged, damit du keine Konflikte bekommst, aber das müsste dann auch noch in die neue log.php: https://github.com/following5/oc-server3/commits/217_masslog_warning

ich habe mir die codestellen schon mal mitgenommen, werde es nach dem bugfixen mit einbauen... die sql-abfrage passt am besten als statische funktion in cachelog.class.php und der rest ist template ein- und ausblenden...

#7 Updated by bohrsty almost 6 years ago

following schrieb:

Review cache.class.php:
  • logTypeAllowed() verwendet noch die obsolete Tabelle cache_logtype. Stattdessen muss die Funktion logtype_ok() aus logtypes.inc.php verwendet werden

ist entsprechend angepasst

  • bei updateCacheStatus() sind die Einrückungen des SQL-Statements durcheinandergeraten

die einrueckungen waren mit tabs gemacht, ich habe noch mal eine zeile eingefuegt...

  • getUserLogTypes() hat einen Parameter $userId, der nicht verwendet wird.

artefakt vom loesen des merge-konflikts mit den teamcomments, ist raus...

  • logTypeAllowed(), getUserLogTypes() und teamcommentAllowed() sollten jeweils noch einen zusätzlichen Parameter $oldLogType haben - das ist der Typ eines editierten Logs und wird für die Portierung von editlog.php gebraucht: Man kann beim Editieren eines Logs den Logtyp immer beibehalten, auch wenn man diesen Typ nicht mehr neu loggen darf. Das ist z.Zt. für Admin-Logs beim Bearbeiten von Cachemeldungen relevant. Kann per Default = 0 gesetzt werden.

angepasst und an die funktionen aus logtypes.inc.php weitergegeben, fall verwendet...

Review cachelog.class.php:
  • Vorschlag: in createNewFromCache() auch gleich die NodeID setzen, da diese Funktion ohnehin nur für lokal erzeugte Logs verwendbar ist.

ich sehe den unterschied nicht, spart aber einen funktionsaufruf in der log.php, ist angepasst...

Review log.php
  • logTypeAllowed() wird mit Parameter null aufgerufen, wenn $_POST['logtype'] nicht gesetzt ist. Erstaunlich, dass das bei dir funktioniert. :-)

naja, null in der datenbank abfragen funktioniert meisten mit einem negativen ergebnis... ;) nun muss deine funktion es abfangen und die frage in_array(null, array()) fuehrt auch in diesem fall zu false und alles ist korrekt...

  • Der Parameter 'rating' wird nicht validiert. Per direkten Aufruf von log.php?cacheid=nnn&rating=1&... kann man Ratings jenseits seiner Rating-Quota und Ratings ohne Fund erzeugen.

ist allerdings ein post-wert, kann also nur ocprop unfug mit anstellen, aber ich habe mal die pruefung auf "hat der user noch ratings" eingebaut...

  • Die Template-Variable 'octeamcomment' wird anscheinend bei Admin-Logs immer auf true gesetzt. Das sollte aber nur passieren, wenn der Cache gesperrt (Status 6 oder 7) bzw. das Loggen für Nichtadmins verboten ist und es kein eigener Cache ist.

laut der vorlage vor der umstellung soll es so sein, eine negierung fehlte allerdings...

  • In Zeile 53 wird per
    [...]
    das Loggen aller veröffentlichten Caches erlaubt, auch wenn sie gesperrt sind (status = 6 oder 7).
  • Benennung und Inhalt der Variable $error widersprechen sich - $error['logPw']=true suggeriert z.B. "falsches Logpasswort". Ich denke $validate wäre passend - es geht um die Validierung von Eingabewerten.

ist korrigiert...

Konfiguration:
  • Eintrag $opt['html_purifier']['cache_path'] in settings-dist.inc.php fehlt - sollte wohl cache2/html_purifier sein?

ist eingetragen, der pfad muss allerdings absolut sein, also lautet der eingtrag jetzt: $opt['html_purifier']['cache_path'] = basename(__FILE__).'/../cache2/html_purifier/';

Test:
Nachdem ich den Konfigurationseintrag für $opt['html_purifier']['cache_path'] in meiner settings.inc.php gesetzt habe, kommt beim Versuch einen Cache zu loggen Folgendes:

Warning: chmod() [function.chmod]: Die Operation ist nicht erlaubt in /mnt/server-3.0/htdocs/lib2/HTMLPurifier/library/HTMLPurifier/DefinitionCache/Serializer.php on line 112 > > 1

... und sonst nichts mehr. In config2/html_purifier wurde irgendwas angelegt, also das Verzeichnis ist beschreibbar.

s.o.

ausserdem halte ich es fuer unsinnig, dass owner ihre eigenen caches bewerten koennen, ich habe das mal mit korrigiert ;)

#8 Updated by following almost 6 years ago

bohrsty schrieb:

  • logTypeAllowed() wird mit Parameter null aufgerufen, wenn $_POST['logtype'] nicht gesetzt ist. Erstaunlich, dass das bei dir funktioniert. :-)

naja, null in der datenbank abfragen funktioniert meisten mit einem negativen ergebnis... ;) nun muss deine funktion es abfangen und die frage in_array(null, array()) fuehrt auch in diesem fall zu false und alles ist korrekt...

Hmja, weil es keinen Logtyp 0 gibt. in_array macht einen einfachen Vergleich, da ist null == 0. Hab mal dokumentiert dass der Parameter null sein kann.

  • In Zeile 53 wird per
    [...]
    das Loggen aller veröffentlichten Caches erlaubt, auch wenn sie gesperrt sind (status = 6 oder 7).

ist korrigiert...

Nach nochmaligem drüberschauen: $cache->allowLog() fängt bereits alle möglichen Fälle ab, der Rest ist redundant. Hab es mal auf $cache->allowLog() reduziert.

ausserdem halte ich es fuer unsinnig, dass owner ihre eigenen caches bewerten koennen, ich habe das mal mit korrigiert ;)

Es gibt einen seltenen Fall wo es Sinn macht, nämlich Nachlog bei einem adoptierten Cache. Solche Nachlogs hab ich tatsächlich schon gesehen, aber in der Kombination mit Empfehlung ist es sicher so selten dass man's vernachlässigen kann.

Was mir noch aufgefallen ist:

- Über der Überschrift der Logseite ist eine Leerzeile entstanden. Das könnte daran liegen, dass sich ein Unicode Byte Order Mark in die Datei eingeschlichen hat; vgl. #177.

- Die Überschrift ist nicht mehr ins Deutsche übersetzbar: "Einen Logeintrag für den Cache $CACHE hinzufügen" ... Es war schon Absicht, dass der verlinkte Cachename Teil des zu übersetzenden Strings war. :-)

- Die Logtyp-Vorgabe beim Abarbeiten von Cachemeldungen funktioniert nicht mehr. Liegt es daran, dass es per $_POST[] ausgewertet wird? Das war aber früher auch so und hat funktioniert, ebenso wie beim teamcomment-Parameter der ebenfalls über die URL angegeben wird.

Wenn früher auch alle Parameter per URL-Übergabe funktionierten und jetzt nicht mehr (warum?), wäre es sinnvoll das alles auf $_REQUEST[] umzustellen. Wer weiß was es noch an Seiten und Tools gibt, die dieses Feature nutzen und direkt auf die Logseite zugreifen.

- Die Rotfärbung des OC-Team-Kommentar-Labels funktioniert nicht mehr. Es sollte class="redtext" haben wenn man als Admin einen fremden, gesperrten (Status 6 oder 7) Cache loggt, d.h. immer dann wenn auch der Log-Button im Listing rot hinterlegt ist.

- Der Hinweis auf die Fundzahl beim Loggen gefällt mir persönlich gar nicht - ich logge nicht wegen der Statistik, und ich will sie schon gar nicht sehen wenn ich ein DNF oder ein Wartungslog für einen meiner Caches eintrage. Zudem schiebt sich dadurch der "Log-eintragen"-Button bei meinen Browsereinstellungen gerade so weit nach unten, dass ich zum Absenden runterscrollen muss (auch wenn die Leerzeile ganz oben wieder weg ist).

Wenn dieses Feature bleibt möchte ich es zumindest im Profil abschalten können; am liebsten wäre mir wenn es per Default aus ist. Das kann ich notfalls auch selbst einbauen.

Wenn die Bugs behoben sind, baue ich noch die Übersetzungen rein und lege es auf den Testserver. Meine Änderungen kannst du wie folgt bei dir einmergen:

#9 Updated by bohrsty almost 6 years ago

following schrieb:

ausserdem halte ich es fuer unsinnig, dass owner ihre eigenen caches bewerten koennen, ich habe das mal mit korrigiert ;)

Es gibt einen seltenen Fall wo es Sinn macht, nämlich Nachlog bei einem adoptierten Cache. Solche Nachlogs hab ich tatsächlich schon gesehen, aber in der Kombination mit Empfehlung ist es sicher so selten dass man's vernachlässigen kann.

den fall habe ich auch mal mit abgefragt, also wenn man owner ist und den cache adoptiert hat (und die anderen voraussetzungen stimmen) kann man empfehlen ;)

Was mir noch aufgefallen ist:

- Über der Überschrift der Logseite ist eine Leerzeile entstanden. Das könnte daran liegen, dass sich ein Unicode Byte Order Mark in die Datei eingeschlichen hat; vgl. #177.

tatsaechlich, wie auch immer es dahingekommen ist...

- Die Überschrift ist nicht mehr ins Deutsche übersetzbar: "Einen Logeintrag für den Cache $CACHE hinzufügen" ... Es war schon Absicht, dass der verlinkte Cachename Teil des zu übersetzenden Strings war. :-)

das problem wird noch haeufiger bei der migration zur lib2 auftauchen, denn der uebersetzungsstring in sys_trans_text lautet:
'Logeintrag f\ür den Cache <a href=\"viewcache.php?cacheid={cacheid}\">{cachename}</a> hinzuf\ügen'
in der lib2 kommen die ersetzungen von {...}-variablen eigentlich nicht mehr vor (trennung von daten und layout)... auch in der lib1 wird der cachename (inkl. link) nicht uebersetzt...
ich waere dafuer den reinen text im template zu uebersetzen ({t}{/t}) und die veraenderbaren daten ausserhalb zu lassen wie in meinem code vorgeschlagen...

- Die Logtyp-Vorgabe beim Abarbeiten von Cachemeldungen funktioniert nicht mehr. Liegt es daran, dass es per $_POST[] ausgewertet wird? Das war aber früher auch so und hat funktioniert, ebenso wie beim teamcomment-Parameter der ebenfalls über die URL angegeben wird.

Wenn früher auch alle Parameter per URL-Übergabe funktionierten und jetzt nicht mehr (warum?), wäre es sinnvoll das alles auf $_REQUEST[] umzustellen. Wer weiß was es noch an Seiten und Tools gibt, die dieses Feature nutzen und direkt auf die Logseite zugreifen.

kann ich gerade nicht nachvollziehen, muss ich noch mal durchgucken, aber es waere auch kein problem auf $_REQUEST[] um zu stellen

- Die Rotfärbung des OC-Team-Kommentar-Labels funktioniert nicht mehr. Es sollte class="redtext" haben wenn man als Admin einen fremden, gesperrten (Status 6 oder 7) Cache loggt, d.h. immer dann wenn auch der Log-Button im Listing rot hinterlegt ist.

ich kann den fehler nicht entdecken, die abfrage muesste identisch zur alten version und zur viewcache.php sein (wenn loggen nicht erlaubt ist und der user admin ist)... vielleicht bin ich auch betriebsblind...

- Der Hinweis auf die Fundzahl beim Loggen gefällt mir persönlich gar nicht - ich logge nicht wegen der Statistik, und ich will sie schon gar nicht sehen wenn ich ein DNF oder ein Wartungslog für einen meiner Caches eintrage. Zudem schiebt sich dadurch der "Log-eintragen"-Button bei meinen Browsereinstellungen gerade so weit nach unten, dass ich zum Absenden runterscrollen muss (auch wenn die Leerzeile ganz oben wieder weg ist).

Wenn dieses Feature bleibt möchte ich es zumindest im Profil abschalten können; am liebsten wäre mir wenn es per Default aus ist. Das kann ich notfalls auch selbst einbauen.

da hast du vollkommen recht, hier geht es erstmal nur um die uebernahme in die lib2 und bugfixes und nicht um neue features (ich hatte es mit eingebaut, weil meine frau gerade loggen wollte als ich dran sass und sagte "wo sehe ich bei oc eigentlich wieviele funde ich habe?" ;) )
ich habe es im template jetzt ausblendbar gemacht (und ausserhalb des formulars verschoben) und ueber die function "showStatFounds()" aus user.class.php konfigurierbar gemacht... die function liefert standardmaessig false, bis jemand im profil eine entsprechende option einbaut und die funktion anpasst (s. #241)

#10 Updated by following almost 6 years ago

bohrsty schrieb:

'Logeintrag f\ür den Cache <a href=\"viewcache.php?cacheid={cacheid}\">{cachename}</a> hinzuf\ügen'
in der lib2 kommen die ersetzungen von {...}-variablen eigentlich nicht mehr vor (trennung von daten und layout)...

In Übersetzungsstrings sind die %1/%2/%3-Variablen der lib2 das gleiche wie die {...}-Variablen der lib1. Du meintest sicher, dass sie sauberer verwendet werden, also kein HTML-Code mehr per Variablen an die Templates übergeben wird?

Der Cachelink in der lib1-Variante wurde auch mit übersetzt (natürlich ohne den Namen, sry):

{t}Add log-entry for the cache <a href="viewcache.php?cacheid={cacheid}">{cachename}</a>{/t}

Sowas kommt auch in lib2 vor, aber es ist natürlich unschön. Vielleicht lässt es sich so lösen, dass man ohne HTML im Übersetzungsstring auskommt?

ungetestet:

{assign var=cachelink value='<a href="viewcache.php?cacheid={$cacheid}">{$cachename}</a>'}
{t 1=$cachelink}Add log-entry for the cache %1{/t}

Auf jeden Fall wäre es schön wenn die Position des verlinkten Namens als Variable im Übersetzungsstring bleibt; man wäre sonst zu eingeschränkt beim Übersetzen.

.

- Die Rotfärbung des OC-Team-Kommentar-Labels funktioniert nicht mehr. Es sollte class="redtext" haben wenn man als Admin einen fremden, gesperrten (Status 6 oder 7) Cache loggt, d.h. immer dann wenn auch der Log-Button im Listing rot hinterlegt ist.

ich kann den fehler nicht entdecken, die abfrage muesste identisch zur alten version und zur viewcache.php sein (wenn loggen nicht erlaubt ist und der user admin ist)... vielleicht bin ich auch betriebsblind...

alte Version:

$adminlog = !($record['log_allowed']) && $useradmin;
$tco =  mb_ereg_replace('{textclass}', ($adminlog ? 'redtext' : ''), $tco);

neue Version:

$tpl->assign('octeamcommentclass', (!$cache->allowLog() && $useradmin) ? 'redtext' : '');

$cache->allowLog() verhält sich anders als das Feld 'log_allowed' aus der Tabelle cache_status: Es ist für User-Admins immer true, daher wird redtext nie gesetzt. Gleiches Problem eine Zeile drüber beim Setzen von 'octeamcomment'.

Hier braucht es wohl zwei Varianten von allowLog(): Eine die testet, ob ein Cache von "einfachen Benutzern" geloggt werden darf, und eine die den Status des angemeldeten Users mit berücksichtigt.

#11 Updated by bohrsty almost 6 years ago

following schrieb:

[...]
Auf jeden Fall wäre es schön wenn die Position des verlinkten Namens als Variable im Übersetzungsstring bleibt; man wäre sonst zu eingeschränkt beim Übersetzen.

mit {assign} und {eval} funktioniert es nicht, denn assign hat offenbar probleme mit leerzeichen und "="... mit {capture}{/capture} kann man es aber wunderbar loesen und der komplette link/name kann in der uebersetzung verwendet werden...

- Die Rotfärbung des OC-Team-Kommentar-Labels funktioniert nicht mehr. Es sollte class="redtext" haben wenn man als Admin einen fremden, gesperrten (Status 6 oder 7) Cache loggt, d.h. immer dann wenn auch der Log-Button im Listing rot hinterlegt ist.

[...]
$cache->allowLog() verhält sich anders als das Feld 'log_allowed' aus der Tabelle cache_status: Es ist für User-Admins immer true, daher wird redtext nie gesetzt. Gleiches Problem eine Zeile drüber beim Setzen von 'octeamcomment'.

Hier braucht es wohl zwei Varianten von allowLog(): Eine die testet, ob ein Cache von "einfachen Benutzern" geloggt werden darf, und eine die den Status des angemeldeten Users mit berücksichtigt.

die alte version macht den vergleich mit "cache_status.allow_user_log" bei entsprechendem "caches.status", um die logbarkeit fest zu stellen, ich habe also in cache.class.php die funktion statusUserLogAllow() mit folgender abfrage erstellt:
SELECT `cache_status`.`allow_user_log`
FROM `cache_status`,`caches`
WHERE `caches`.`status`=`cache_status`.`id`
AND `caches`.`cache_id`='&1'

wenn diese funktion false liefert (der cache also irgendeinen sperrstatus hat) und der user admin ist, wird rot eingefaerbt...

ich hoffe, dass nun alle bug behoben sind und die aenderung in den test gehen kann ;)

#12 Updated by following almost 6 years ago

den fall habe ich auch mal mit abgefragt, also wenn man owner ist und den cache adoptiert ha

Da hattest du ja Glück, dass ich vor zwei Wochen das hier eingebaut hatte. ;)

Bei meinem Posting Nr. 3 oben hatte ich noch etwas vergessen zu erwähnen, aber das ist erst mal unabhängig vom weiteren Test:

Bisher wurden Logduplikate kommentarlos ignoriert, und zwar aus zwei Gründen:

1. Der häufigste Grund für Duplikate ist mehrfaches Klicken des Absende-Buttons. Wenn hier eine Warnung/Fehlermeldung erscheint ist das irritierend - das Log wurde ja korrekt eingestellt und nur die weiteren Klicks ignoriert.

2. Der zweithäufigste Grund sind Ocprop-Amokläufe. Es kann sein dass Ocprop auf die Nase fällt, wenn nach dem Posten eines Logs das Logformular erscheint anstatt des Cachelistings (hab ich nicht weiter verifiziert).

D.h. wenn du die Warnung beibehalten möchtest fände ich es sinnvoll, zumindest sehr kurz aufeinanderfolgende Logs zu ignorieren (per date_created) sowie Ocprop-Logs ($ocpropping == true).

#13 Updated by following almost 6 years ago

  • Status changed from in Arbeit 20% to im Test

Habs auf den Testserver gelegt; vielen Dank soweit!

Einen Tippfehler habe ich noch korrigiert, und das hier:

alert(navigator.appName + ": {t}Setting smilies is not supported{/t}");

Der Code steht in einem Literal-Block, d.h. alle Smarty-Tags außer "{/literal}" werden ignoriert. Daher muss man das literal für die Übersetzung abschalten:

alert(navigator.appName + ": {/literal}{t}Setting smilies is not supported{/t}{literal}");

Meine Änderungen kannst du wie gehabt aus meinem Fork holen und mergen.

Beim Testen sind mir noch zwei Probleme aufgefallen:
  • Der CSS-Style für die Höhe des Editorfensters wird ignoriert - allerdings nur auf meinem Entwicklersystem, nicht auf test.opencaching.de!?
  • Wenn das Verzeichnis htdocs/cache2/html_purifier bis auf .htaccess leer ist, bekomme ich bei Verwendung des Editors folgende Warnung:
Warning:  chmod() [function.chmod]: Die Operation ist nicht erlaubt in
/mnt/server-3.0/htdocs/lib2/HTMLPurifier/library/HTMLPurifier/DefinitionCache/Serializer.php on line 112

Die kam mehrmals, bis der "Serializer" alle benötigten Unterverzeichnisse angelegt hatte. D.h. diese Verzeichnisse sollten auch bereits im Git-Repo anlegt sein. Das dürften die drei sein, die auch in der .gitignore stehen: CSS, HTML und URI (können dort dann raus, da cache2 komplett ignoriert wird).

.
Und noch eine Bitte: Englische, zu übersetzende Texte in den Templates bitte nur ändern, wenn der Text inhaltlich falsch, unverständlich oder missverständlich ist! Die werden ohnehin nochmal ins Englische "übersetzt", also diese Texte erscheinen nirgendwo sondern dienen nur als Übersetzungsvorlage. Bei jeder Änderung muss ich das Übersetzungsorginal in data.sql anpasse, wenn ich's nicht gerade vergesse; daher Rechtschreibfehler bitte stehenlassen (oder die Anpassungen in data.sql selbst machen).

#14 Updated by following almost 6 years ago

Hast du eigentlich absichtlich den Tabellen-Toolbar im Editor eingeblendet? Ich denke den braucht man bei Logs so gut wie nie, aber er nimmt Platz weg ...

#15 Updated by bohrsty almost 6 years ago

following schrieb:

Habs auf den Testserver gelegt; vielen Dank soweit!

danke dir fuers geduldige reviewen ;)

Einen Tippfehler habe ich noch korrigiert, und das hier:

[...]

Der Code steht in einem Literal-Block, d.h. alle Smarty-Tags außer "{/literal}" werden ignoriert. Daher muss man das literal für die Übersetzung abschalten:

[...]

da sucht man schon nach "{" und "}" und uebersieht doch noch welche...

Und noch eine Bitte: Englische, zu übersetzende Texte in den Templates bitte nur ändern, wenn der Text inhaltlich falsch, unverständlich oder missverständlich ist! Die werden ohnehin nochmal ins Englische "übersetzt", also diese Texte erscheinen nirgendwo sondern dienen nur als Übersetzungsvorlage. Bei jeder Änderung muss ich das Übersetzungsorginal in data.sql anpasse, wenn ich's nicht gerade vergesse; daher Rechtschreibfehler bitte stehenlassen (oder die Anpassungen in data.sql selbst machen).

ok... daran habe ich nicht mehr gedacht, ich hatte es angepasst, weil die "uebersetzungsvorlage" im code eh angepasst werden musste ({...} zu %...), ich lasse es in zukunft sein ;)
der uebersetzungs-workflow ist doch aber noch so, dass moeglichst nur einer (bisher du) anpassungen an den uebersetzungen macht um merge-konflikte zu vermeiden, oder?

Hast du eigentlich absichtlich den Tabellen-Toolbar im Editor eingeblendet? Ich denke den braucht man bei Logs so gut wie nie, aber er nimmt Platz weg ...

ich habe am javascript-code (und eigentlich auch am restlichen template) ausser den uebersetzungs-aenderungen und dem zusammenfuehren der verschiedenen templatedateien nichts angepasst... ich wuesste nicht mal wo die konfig herkommt, da es zum portieren eigentlich nicht notwendig ist...

#16 Updated by following almost 6 years ago

bohrsty schrieb:

der uebersetzungs-workflow ist doch aber noch so, dass moeglichst nur einer (bisher du) anpassungen an den uebersetzungen macht um merge-konflikte zu vermeiden, oder?

-> #101

#17 Updated by bohrsty almost 6 years ago

bohrsty schrieb:

[...]

Hast du eigentlich absichtlich den Tabellen-Toolbar im Editor eingeblendet? Ich denke den braucht man bei Logs so gut wie nie, aber er nimmt Platz weg ...

ich habe am javascript-code (und eigentlich auch am restlichen template) ausser den uebersetzungs-aenderungen und dem zusammenfuehren der verschiedenen templatedateien nichts angepasst... ich wuesste nicht mal wo die konfig herkommt, da es zum portieren eigentlich nicht notwendig ist...

das ist so ein typischer fall von "kopf meets notebooktastatur (wenn in der bahn genug platz waere)"... ich war es doch... allerdings unbewusst bzw. aus schlusigkeit... ich wollte wissen, wie man die javascript-header in der lib2 einfuegt und habe (wissend, dass es die einzige stelle ist wo der tinymce in der lib2 verwendet wird) die funktionsaufrufe aus dem userprofile kopiert... und sie am ende nicht geprueft... ist also ein sogenannter "copy and paste bug" ;) ich behalte das mal im hinterkopf, dass es vor der uebernahme in den stable-branch noch mal angepasst werden muss...

#18 Updated by following almost 6 years ago

Folgende Punkte sind noch offen:
  • Logduplikate kommentarlos ignorieren, wenn mehrfach "absenden" gedrückt wurde oder beim Einstellen via Ocprop (oder wahlweise verifizieren, dass Ocprop keine Probleme mit der Fehleranzeige hat)
  • Tabellen-Toolbar wieder ausblenden
  • Einstellung für Editor-Fensterhöhe wird u.U. ignoriert (gleiche Ursache wie beim Tabellen-Toolbar?)
  • Leerverzeichnisse für HTML-Purifier-Temporärdaten anlegen

#19 Updated by bohrsty almost 6 years ago

following schrieb:

Folgende Punkte sind noch offen:
  • Logduplikate kommentarlos ignorieren, wenn mehrfach "absenden" gedrückt wurde oder beim Einstellen via Ocprop (oder wahlweise verifizieren, dass Ocprop keine Probleme mit der Fehleranzeige hat)

meldung und zugehoeriger code ist wieder komplett raus und wird kommentarlog ignoriert...

  • Tabellen-Toolbar wieder ausblenden
  • Einstellung für Editor-Fensterhöhe wird u.U. ignoriert (gleiche Ursache wie beim Tabellen-Toolbar?)

tinymce-config korrigiert, tabellentoolbar ist weg und editorfenster laesst sich anpassen...

  • Leerverzeichnisse für HTML-Purifier-Temporärdaten anlegen

die legt der purifier automatisch an, habe ich im neuen entwicklerimage getestet (ohne fehlermeldung), ich vermute mal, dass die fehlermeldung in den lokalen tests mit den unterschiedlichen dateisystemen (ntfs kennt chmod nicht) und den berechtigungen (nur der owner darf chmod ausfuehren) zusammenhaengt, bei beiden muesste die fehlermeldung "operation not permitted" heissen... wenn ich bei mir lokal die verzeichnisse anlege und leer lasse, kommt die fehlermeldung trotzdem beim anlegen der serializer-datei (lokales dateisystem = ntfs)...

#20 Updated by following almost 6 years ago

  • % Done changed from 50 to 100

bohrsty schrieb:

meldung und zugehoeriger code ist wieder komplett raus und wird kommentarlog ignoriert...

Ein Kommentar erscheint nicht mehr, aber es passiert auch sonst nichts - das Logformular bleibt offen. Hab das nun geändert, sodass es kommentarlos geschlossen wird, so wie früher.

tinymce-config korrigiert, tabellentoolbar ist weg und editorfenster laesst sich anpassen...

Ok. Das mit dem CSS-Stil für die Fensterhöhe ist immer noch so, aber ich merke gerade dass das ein Feature ist und auch früher schon so war: Sobald man die Höhe des Fensters geändert hat, merkt der Editor sich das (Cookie?) und behält diese Höhe bei.

ich vermute mal, dass die fehlermeldung in den lokalen tests mit den unterschiedlichen dateisystemen (ntfs kennt chmod nicht) und den berechtigungen (nur der owner darf chmod ausfuehren) zusammenhaengt

Hmja, hab es eben nochmal auf test.opencaching.de probiert und dort kam keine Warnung.

Ist nun im Master, aber da ich nochmal einen Rebase gemacht habe ist dein Branch nicht weiterverwendbar. Also wenn du nochmal was dran machen solltest musst du einen neuen anlegen.

#21 Updated by following almost 6 years ago

  • Kategorien changed from system to logs system

#22 Updated by bohrsty almost 6 years ago

  • Target version set to Version 9

#23 Updated by following almost 6 years ago

  • Status changed from im Test to erledigt

Also available in: Atom PDF