Discussion about bug fixing and planned features for mlf 2.4

Hello

While the version 2.3.7beta2 is undertaken the last tests, we should discuss the list for the version 2.4. We have collected the first few points that should be fixed respectively included. Aside from that I found a few threads with error reportings and wishes in this project forum.

I will offer a list of the points with questions and notices (in bold text).

Show views of all entries in a thread instead only of the opening entry in the table view (thread in a hidden category and thatswhy not linked).
Is this fixed?
Status 404 for images in a custom theme. It's probably an error of the theme creator, but maybe not.
Should be investigated.
There seems to be a RSS-issue, where new entries doesn't show up instantaneously in some clients. Maybe client-issues, maybe a problem with time format?
Should be investigated.
A second issue with RSS, that came up a few minutes ago. The feed is updated every time a new entry is posted. There is no update in case od a deletion of an entry or a thread. An entry will furthermore reside in the feed even if it is removed from the forum.
Should be investigated.
Images in the feed was reported to be broken (wrong path given).
Is this fixed? (my feed-reader only provides the entries headers and some metadata)
A problem with the Ajax-preview-bubble was reported.
I for myself can't confirm the behaviour. On the other hand images should IMHO shrinked to a bit less of 100% of the width and/or height.
A feature request was to have infinite scrolling in the overview pages.
I personally like the idea, am not able to realise it and have no clue about the effort.
A further request is to have a report-spam/abuse-link or button.
Is this of any importance? I would support it in principle but don't want to exceed the task list.
Someone wanted to have tab order for buttons, mainly in the posting form.
This is (not only!) important for disabled persons. But at that point I have further questions about the UI and especially the font size.

Please consider to offer your thoughts about one, a few or all of the points. I want to know if you think, that special points are very important or of no importance. Or, if you think, that one or another point is very complex or easy to realise. I then will trnasmit the chosen points to the issue list in the Github-repository.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hello

I found the RSS- and Atom-feeds of the Github-repository in the source of the releases page. There are special feeds for the last commits, the tags and for the releases. I think, this overture is worth to think about an overhauled update notification. The update process in itself should stay untouched.

Actually the admin can detect the installed version in the admin area and has to check a website (that can change from time to time) for the presence of a newer version. My idea is, to list the atom-feed of the releases (header and date) in the admin area. Maybe only newer versions than the installed because the version string is detectable in the feed, so we can determine it.

<id>tag:…,2008:Repository/60085679/v2.3.7beta2</id>
<link rel="alternate" type="text/html" href="/ilosuna/mylittleforum/releases/tag/v2.3.7beta2"/>

That said, I wish to show the up-to-date version anywhere in the admin area or, only for admins at the top of the side- or bottombar.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo Milo

Ich habe mal ein paar Tests zu der vorgeschlagenen Benachrichtigung über neue Versionen angestellt und komme partout nicht weiter. Ich bin mir, seitdem Alfie und ich vor mehreren Jahren ein paar Tests zu Server-zu-Server-Verbindungen durchgeführt haben, der Tatsache bewusst, dass ich schlechte Karten habe, wenn ich von meinem Server (PHP-Skript) aus eine Verbindung zu einem anderen Server herstellen will. Von Alfies Server konnten wir den meinen kontaktieren, aber nicht von meinem Server aus den seinen.

Jetzt habe ich sowohl mit dem Atom-Feed zu den Releases [1] als auch mit dem offiziellen Weg über die API [2] versucht, die Releases abzufragen; ich bekomme es einfach nicht hin. Rufe ich die in den Fußnoten vermerkten URLs im Browser auf, erhalte ich im ersten Fall eine XML- und im zweiten Fall eine JSON-Ressource. Über ein PHP-Skript kriege ich es aber nicht hin. Der Weg über fopen oder file_get_contents bleibt mir versperrt, weil das die Konfiguration meines Webspaces nicht hergibt. Mit der alternativen Anbindung per curl wird mir die Verbindung abgelehnt (refused).

Anbei die Ausgabe von curls verbose:

https://api.github.com/repos/ilosuna/mylittleforum/releases

cUrl error (#7): couldn't connect to host

Verbose information:

* About to connect() to api.github.com port 443 (#0)
*   Trying 192.30.253.116...
* Connection refused
* couldn't connect to host
* Closing connection #0

Nun weiß ich nicht, ob das an meiner Serverkonfiguration liegt, oder ob ich einfach nur zu blöd bin. Kannst du bitte mal folgenden Code als PHP-Skruipt abspeichern, hochladen, ausführen und berichten, was dabei herauskommt?

<?php
 
header("Content-Type: text/html; charset=utf-8");
ini_set('display_errors', 1);
error_reporting(E_ALL);
 
/**
 * wrapper to load an external ressource into a variable
 *
 * @param string $url
 * @return bool false
 * @return string $string
 */
function my_load_external_feed($url) {
  if ($url === NULL) return false;
  if (filter_var($url, FILTER_VALIDATE_URL) === false) return false;
 
  $string = '';
 
  if (function_exists('curl_init')) {
    # read the xml-ressource from the URL with curl
    $verbose = fopen('php://temp', 'w+');
    $c = curl_init($url);
    curl_setopt($c, CURLOPT_VERBOSE, true);
    curl_setopt($c, CURLOPT_STDERR, $verbose);
    curl_setopt($c, CURLOPT_SSLVERSION, 6);
    curl_setopt($c, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($c, CURLOPT_CONNECTTIMEOUT, 2);
    curl_setopt($c, CURLOPT_FORBID_REUSE, true);
    $string = curl_exec($c);
    if ($string === FALSE) {
      printf("<pre>cUrl error (#%d): %s</pre>\n", curl_errno($c),
        htmlspecialchars(curl_error($c)));
    }
    rewind($verbose);
    $verboseLog = stream_get_contents($verbose);
    echo "<p>Verbose information:</p>\n<pre>", htmlspecialchars($verboseLog), "</pre>\n";
    curl_close($c);
  } else {
    return false;
  }
return $string;
}
 
#$test = "https://github.com/ilosuna/mylittleforum/releases.atom";
$test = "https://api.github.com/repos/ilosuna/mylittleforum/releases";
 
echo '<pre>'. print_r($test, true) .'</pre>';
 
$ret = my_load_external_feed($test);
 
#echo '<pre>';
#var_dump($ret);
#echo '</pre>';

echo '<pre>'. print_r(json_decode($ret), true) .'</pre>';
 
?>

Mit bestem Dank im voraus,

tschö, Auge

[1] https://github.com/ilosuna/mylittleforum/releases.atom
[2] https://api.github.com/repos/ilosuna/mylittleforum/releases

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi Auge,

der Code funktioniert bei mir auch nicht. Ich habe noch etwas rumprobiert, da wir im Forum ja zum SPAM-Schutz die Mailadressen/Nutzernamen an stopforumspam.com weiterleiten und eine XML zurückbekommen, vgl. Zeile 2528ff in function.inc.php. Leider musste ich feststellen, dass mein Provider HTTPS-Verbindungen nicht unterstützt, vgl. stream_get_wrappers(). Ich habe leider keine Möglichkeit, dies zu konfigurieren und GitHub unterstützt keine HTTP-Verbindungen (301 --> HTTPS).

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo Milo

der Code funktioniert bei mir auch nicht.

*grmpf*

Schade. Ich hatte gehofft, dass das nur ein Problem mit der Konfiguration meines Webspaces ist und ein Test von einem anderen Server erfolgreich verläuft. Auf meinem Server/Webspace kann ich nun leider nicht feststellen, ob es an der Konfiguration oder am Code (vielleicht fehlt irgendwas, das ich nicht identifizieren kann) liegt.

Ich habe noch etwas rumprobiert, da wir im Forum ja zum SPAM-Schutz die Mailadressen/Nutzernamen an stopforumspam.com weiterleiten und eine XML zurückbekommen, vgl. Zeile 2528ff in function.inc.php.

Funktioniert das bei dir? Wenn ich mich nicht versehen habeIch hatte bisher immer gedacht, dass fsockopen bei mir abgeschaltet sei. Laut phpinfo gehört die Funktion aber nicht zu den abgeschalteten. Ich werde den Code mal testweise adaptieren.

Leider musste ich feststellen, dass mein Provider HTTPS-Verbindungen nicht unterstützt, vgl. stream_get_wrappers(). Ich habe leider keine Möglichkeit, dies zu konfigurieren und GitHub unterstützt keine HTTP-Verbindungen (301 --> HTTPS).

Laut stream_get_wrappers() unterstützt mein Hoster sehr wohl HTTPS.

# input:
echo '<pre>'. print_r(stream_get_wrappers(), true) .'</pre>';

# output:
Array
(
    [0] => https          # <= da isser
    [1] => ftps
    [2] => compress.zlib
    [3] => compress.bzip2
    [4] => php
    [5] => file
    [6] => glob
    [7] => data
    [8] => http
    [9] => ftp
    [10] => phar
    [11] => zip
)

Ich werde sowohl den Weg über fsockopen probieren als auch weitere Recherchen über die zu setzenden Parameter für curl anstellen. Danke erstmal.

Tschö, Auge

PS: Sollten wir den finalen 2.3.7-er Release mit den bereits übernommenen PRs fertig machen? Dann könnten wir dieses Kapitel abschließen und ohne zwischen 2.3.7 und 2.4 hin-und-her denken zu müssen, die neuen Sachen anpacken.

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo Auge,

so, ich habe das ganze Wochenende an dem Bookmark-Feature rumgebastelt und leider nicht bemerkt, dass ich in einer Testumgebung arbeite, die nicht mit GitHub verbunden war. :-( Dass ist mir dann heute bewusst geworden, als ich es hochladen wollte. Folglich enthält mein PR mehrere Sachen. Ich muss das noch anders managen. Kann ich GitHub so konfigurieren, dass bestimme Files nicht überwacht werden wie bspw. die config-Files mit sensiblen Daten?

Funktioniert das bei dir?

Stopforum-Spam wird abgefragt, ja. Aber ich konnte den Code nicht so modifizieren, dass er auch den Feed von GitHub ausliest. Das werde ich auch nie können, da HTTPS nicht von meinem Provider unterstützt wird:

Array
(
    [0] => php
    [1] => file
    [2] => glob
    [3] => data
    [4] => http
    [5] => ftp
    [6] => phar
)

Ich werde sowohl den Weg über fsockopen probieren als auch weitere Recherchen über die zu setzenden Parameter für curl anstellen.

Sollte curl gehen, wäre das schön. Mit fsockopen kommst Du bei mir nicht weit, siehe oben. Insgesamt ist es problematisch, da wie nie wissen, was der Endanwender zur Verfügung hat.

PS: Sollten wir den finalen 2.3.7-er Release mit den bereits übernommenen PRs fertig machen?

Ja, kannst Du mache. Den Weg über die Betas sollten wir zukünftig überdenken! Ein User, der die erste Beta installiert hat, wie die zweite Beta oder das Final nicht mehr über die Updatefunktion einspielen können, wenn sich die Version nicht ändert.

Dann könnten wir dieses Kapitel abschließen und ohne zwischen 2.3.7 und 2.4 hin-und-her denken zu müssen, die neuen Sachen anpacken.

Ich würde gar nicht so viel in Versionen denken. Wenn etwas fertig ist, kommt es in den Master und ist im nächsten Release dabei. Ich erkenne keinen Vorteil darin, etwas fertiges dem User vorzuenthalten nur weil es für eine andere Version geplannt war. Ich würde daher Dein „release early, release often“ eher leben als den Code zu kategorisieren.

Ich habe Dir einen neuen PR mal hingeworfen, der gleich vier Sachen beinhaltet. Der Fokus lag auf der Bookmark Funktion von Postings, der Rest war, wie oben beschrieben, halt mit dabei. Ich hoffe, mir sind keine Neuerungen durch die Lappen gegangen!

Ich habe das PR auch gleich mal zum Anlasse genommen, um etwas aufzuräumen im Update-Script. Für die Bookmarks habe ich eine neue Tabelle hinzugefügt in der DB. Mir ist nicht ganz klar, wie diese durch das Updatescript dann in die config-Datei kommt. Ich habe es mal als Kommentar hingeschrieben aber das ist keine schöne Lösung und spätestens bei der Nachfolgeversion unglückliche. Hier hast Du sicher noch was besseres auf Lager. ;-)

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo Milo

Kann ich GitHub so konfigurieren, dass bestimme Files nicht überwacht werden wie bspw. die config-Files mit sensiblen Daten?

Ja, du kannst in einer Datei namens .gitignore den Pfad relativ zur .gitignore notieren. Ein mMn gutes Beispiel ist im Ubuntuusers.de-Wiki zu finden. Die Datei berücksichtigt alle Verzeichnisse unterhalb seines eigenen Verzeichnisses. Githubs Hilfe zu .gitignore ist ein guter Startpunkt für weitere Infos.

Achtung: Sind für die fraglichen Dateien schon Commits erfolgt, sind diese weiterhin Bestandteil des Repos!

Stopforum-Spam wird abgefragt, ja. Aber ich konnte den Code nicht so modifizieren, dass er auch den Feed von GitHub ausliest. Das werde ich auch nie können, da HTTPS nicht von meinem Provider unterstützt wird:

Sag' niemals nie. Wenn mehrere Kunden Bedarf haben, wird sich dein Hoster einer Änderung vermutlich nicht verschließen können.

Ich werde sowohl den Weg über fsockopen probieren als auch weitere Recherchen über die zu setzenden Parameter für curl anstellen.

Sollte curl gehen, wäre das schön. Mit fsockopen kommst Du bei mir nicht weit, siehe oben. Insgesamt ist es problematisch, da wie nie wissen, was der Endanwender zur Verfügung hat.

Ich habe mit eeiner Funktion, die die Rohdaten begonnen. Wenn irgendwas nicht funktioniert, fällt als Rückgabewert FALSE aus der Funktion raus. Darauf können wir mit einer Rückfallausgabe reagieren und z.B. den Link zum aktuellen Release mit der Bitte, dort regelmäßig nachzuschauen, anzeigen. Der wird von Github entsprechend behandelt und umgeleitet.

Den Weg über die Betas sollten wir zukünftig überdenken! Ein User, der die erste Beta installiert hat, wie die zweite Beta oder das Final nicht mehr über die Updatefunktion einspielen können, wenn sich die Version nicht ändert.

Warum nicht?

Ich würde gar nicht so viel in Versionen denken. Wenn etwas fertig ist, kommt es in den Master und ist im nächsten Release dabei. Ich erkenne keinen Vorteil darin, etwas fertiges dem User vorzuenthalten nur weil es für eine andere Version geplannt war.

Ich würde schon gerne zwischen Bugfixes für bestehenden Code und neuen Features, die z.B. neue DB-Tabellen oder DB-Tabellen-Felder einführen oder relevante Änderungen am Template-Code erfordern und somit Inkompatibilitäten erzeugen, unterscheiden wollen.

Ich habe das PR … zum Anlasse genommen, um etwas aufzuräumen im Update-Script. Für die Bookmarks habe ich eine neue Tabelle hinzugefügt in der DB.

Nachdem die 2.3.7 jetzt raus ist [1], schaue ich mir das mal an.

Mir ist nicht ganz klar, wie diese durch das Updatescript dann in die config-Datei kommt. Ich habe es mal als Kommentar hingeschrieben aber das ist keine schöne Lösung und spätestens bei der Nachfolgeversion unglückliche. Hier hast Du sicher noch was besseres auf Lager.

Solche Änderungen gabe es doch schon ein paar Mal‽ Es ist ja nicht das erste Mal, dass neue Tabellen hinzukamen. Da sollte sich Beispielcode finden lassen. Wenn nicht, habe ich vergleichbares im 1-er Code.

Tschö, Auge

[1] Ich hoffe, ich habe nichts vergessen, nachdem ich den Tag dreimal erzeugt und nach den ersten zwei Malen festgestellt hatte, etwas vergessen zu haben.

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi Auge,

Ja, du kannst in einer Datei namens .gitignore den Pfad relativ zur .gitignore notieren. Ein mMn gutes Beispiel ist im Ubuntuusers.de-Wiki zu finden. Die Datei berücksichtigt alle Verzeichnisse unterhalb seines eigenen Verzeichnisses. Githubs Hilfe zu .gitignore ist ein guter Startpunkt für weitere Infos.

Okay, dann schaue ich da mal bei diesem GitHubDesktop-Tool. Im Moment fahre ich lokal zweigleisig und das führt eher zu mehr Arbeitsaufwand als zu einer Erleichterung. Da ich bei XAMPP keine Passwörter habe, wäre das nicht SO tragisch aber grundsätzlich auch unschön.

Sag' niemals nie. Wenn mehrere Kunden Bedarf haben, wird sich dein Hoster einer Änderung vermutlich nicht verschließen können.

Ja, dass stimmt aber im Moment sind bei PHP7 noch nicht einmal die mysqli_* Funktionnen dabei, sodass ich nur unter PHP5.6 live testen kann.

Den Weg über die Betas sollten wir zukünftig überdenken!

Warum nicht?

Weil ich im Moment davon ausgehe, dass nur neuere Versionen über das Updatescript berücksichtig werden. Wenn die Version 2.3.7 (beta 1) schon installiert ist, wird das Updatescript eine Version 2.3.7 (beta 2 oder final) nicht updaten, weil die Version doch ident ist oder irre ich - habs nicht ausprobiert?

Solche Änderungen gabe es doch schon ein paar Mal‽ Es ist ja nicht das erste Mal, dass neue Tabellen hinzukamen.

Du hast recht. Es wurden schon mal Tabellen hinzugefügt, wie die Update-Historie zeigt. Aber das Update-Script kam wohl erst später hinzu, sodass dort dieser Fall nicht abgebildet ist (oder ich ihn nicht erkenne).

Da sollte sich Beispielcode finden lassen. Wenn nicht, habe ich vergleichbares im 1-er Code.

Darauf hatte ich gehofft. ;-)

Nachdem die 2.3.7 jetzt raus ist [1], schaue ich mir das mal an.

Super. Ich hoffe, ich habe nicht zuviel vergessen und es ist nachvollziehbar.

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo Milo

.gitignore

Okay, dann schaue ich da mal bei diesem GitHubDesktop-Tool. Im Moment fahre ich lokal zweigleisig und das führt eher zu mehr Arbeitsaufwand als zu einer Erleichterung.

Verständlich, wenn das so ist. Konfigurationsdateien mit Livecode halte ich natürlich auch außerhalb des Repos. Selbst wenn ich eine db_config.php über .gitignore ausblenden wollte, ginge es ja nicht, weil ich eine gleichnamige Datei ohne Livedaten an selbiger Stelle bräuchte. Also kommt die Livedatei gleich aus dem Repo raus und muss, wenn sie denn man auf einer Testinstallation aktualisiert werden muss, aus der anderen Quelle genommen werden. Daran muss ich halt nur denken.

Sag' niemals nie.

Ja, dass stimmt aber im Moment sind bei PHP7 noch nicht einmal die mysqli_* Funktionnen dabei, sodass ich nur unter PHP5.6 live testen kann.

Ach herrje!

Den Weg über die Betas sollten wir zukünftig überdenken!

Warum nicht?

Weil ich im Moment davon ausgehe, dass nur neuere Versionen über das Updatescript berücksichtig werden. Wenn die Version 2.3.7 (beta 1) schon installiert ist, wird das Updatescript eine Version 2.3.7 (beta 2 oder final) nicht updaten, weil die Version doch ident ist oder irre ich - habs nicht ausprobiert?

Nun ja, wenn ich bei den Betaversionen daran gedacht hätte, diese in den Settings explizit als Betaversionen zu bezeichnen, könnte der geneigte Admin im Updateskript auch zwischen den Versionen unterscheiden. Mea Culpa!

Man kann das natürlich mit Mut zum Coden als Admin auch selbst anpassen. In den Arrays und Vergleichen mit allen vorhergehenden Versionen müssen entsprechende Einträge ergänzt und dann der Versionsstring in den Einstellungen angepasst werden.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi,

Daran muss ich halt nur denken.

Richtig, sonst sieht es schon mal blöd aus. Da ich so etwas von Anfang an geahnt hatte, habe ich vorsorglich bei XAMPP keine Passwörter vergeben. In meinem Live-Foren nutze ich diese db_settings-Datei gar nicht sondern eine Datei außerhalb vom Dokumentenroot.

Mit dem Merge zu 2.4 werde ich meine unglückliche Datenhaltung dann mal versuchen umzuorganisieren. Auch bin ich gespannt, wie man Konflikte dann auflöst. Da hatte ich heute den ersten Fall, als ich in den Master in den Bookmark mergen wollte. Mit GitHub-Desktop war ich dann schnell am Ende, da u.a. die index.php einen Konflikt hatte. Ich habe in der Datei dann die <<< >>> Einträge gesichtet und angepasst und mit git add <file> dann auf der Konsole gewerkelt. Das hätte ich mir eleganter vorgestellt...

Ja, dass stimmt aber im Moment sind bei PHP7 noch nicht einmal die mysqli_* Funktionnen dabei, sodass ich nur unter PHP5.6 live testen kann.

Ach herrje!

Und das ist noch untertrieben, wie ich finde.

Nun ja, wenn ich bei den Betaversionen daran gedacht hätte, diese in den Settings explizit als Betaversionen zu bezeichnen, könnte der geneigte Admin im Updateskript auch zwischen den Versionen unterscheiden. Mea Culpa!

Ja, ich hatte die Änderungen von beta 1 auf beta 2 händisch gemacht und es deswegen nicht bemerkt. Wer von einer der beiden Beta-Versionen auf die finale Version will, bekommt jetzt die Meldung:

Error in line 358: This update file doesn't work with the current version.

Man kann das natürlich mit Mut zum Coden als Admin auch selbst anpassen. In den Arrays und Vergleichen mit allen vorhergehenden Versionen müssen entsprechende Einträge ergänzt und dann der Versionsstring in den Einstellungen angepasst werden.

Soviel Mut sollten wir nicht voraussetzen und zukünftig die Versionen 2.3.7.1, 2.3.7.b1 oder so benennen.

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo,

Ich werde sowohl den Weg über fsockopen probieren als auch weitere Recherchen über die zu setzenden Parameter für curl anstellen.

Ich habe das jetzt auch mal gemacht und eine Funktion erstellt, die die externe Ressource über mehrere Wege holen kann: getExternalResource($url). Neben dem Update-Checker wäre die auch geeignet, die Mailadressen über stopforumspam zu prüfen (ist im Code mit umgesetzt).

Jetzt weiß ich nur nicht, was Du alles anzeigen wolltest bei dem Update-Feature. Im Moment werden die Version, die Headline und den zugehörigen Content ausgelesen. Der Content ist aber so lang, dass man diesen nicht rechts in der kleinen Box anzeigen lassen kann. Daher im Moment nur diese minimalistische Variante. Ideen und Verbesserungen kannst Du ja direkt integrieren und dann, wenn Du davon überzeugt bist, mergen.

Beim Testen ist mir aufgefallen, dass wenn man die aktuelle 2.3.7er Version installiert, die Version 2.3.6.1 in der DB steht. Es sind wohl mehrere Files, wo wir diese Version bei neuen Versionen setzen müssen. Vielleicht kann man das zentralisieren...

Dir ein schönes Wochenende
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo

Ich werde sowohl den Weg über fsockopen probieren als auch weitere Recherchen über die zu setzenden Parameter für curl anstellen.

Ich habe das jetzt auch mal gemacht und eine Funktion erstellt, die die externe Ressource über mehrere Wege holen kann: getExternalResource($url). Neben dem Update-Checker wäre die auch geeignet, die Mailadressen über stopforumspam zu prüfen (ist im Code mit umgesetzt).

Ich habe den Code gesehen und einen Kommentar dazu geschrieben. Quintessenz: Du bleibst in der Funktion und führst selbst beim erfolgreichen Auslesen der externen Ressource mit einer Methode, die nicht als Letzte notiert ist, den Rest der Funktion mit den restlichen Methoden aus und überschreibst dabei die bereits ermittelten Werte.

Gib für jeden Zweig return $content; für den Fall des Erfolgs an, das sollte reichen.

Jetzt weiß ich nur nicht, was Du alles anzeigen wolltest bei dem Update-Feature. Im Moment werden die Version, die Headline und den zugehörigen Content ausgelesen. Der Content ist aber so lang, dass man diesen nicht rechts in der kleinen Box anzeigen lassen kann. Daher im Moment nur diese minimalistische Variante.

Ich wollte da auch nur die Versionsnummer des aktuellen bereitstehenden Releases anzeigen. Man kann die natürlich noch mit der der Installation vergleichen und eine Klasse setzen, um den Hintergrund grün oder rot (oder so ähnlich) zu färben. Die Release-Notes und andere weiterführende Infos würde ich aber nicht anzeigen lassen wollen. Wer dem angebotenen Link folgt, sieht sie auf der Github-Seite.

Ideen und Verbesserungen kannst Du ja direkt integrieren und dann, wenn Du davon überzeugt bist, mergen.

Ich werde mir morgen erstmal den Code ziehen und die Änderungen ausprobieren.

Beim Testen ist mir aufgefallen, dass wenn man die aktuelle 2.3.7er Version installiert, die Version 2.3.6.1 in der DB steht. Es sind wohl mehrere Files, wo wir diese Version bei neuen Versionen setzen müssen. Vielleicht kann man das zentralisieren...

Ich weiß nicht, wie das, gerade bei den beiden SQL-Dateien gemacht werden könnte. Das, zumal genau diese Datei nur vor bzw. bei der Installation benutzt wird. Ich werde ein TODO schreiben, das uns beim erstellen eines Releases als Checkliste dienen soll. Mir ist es nämlich bei den beiden Releases, die ich gebaut habe, auch an allen Ecken und Enden passiert, dass ich etwas vergessen habe. Die Commits und die dazugehörigen Nachrichten jenes Tages, an dem ich die 2.3.7 gebaut habe, sprechen in dieser Hinsicht Bände.

Für die Benutzung in der laufenden Installation steht die Versionsnummer in der Datenbank, von wo aus sie z.B. in die main.tpl eingefügt wird. Ansonsten sollte sie nur in den SQL-Dateien für Installation und Update und in den Installations- und Update-Skripten stehen, oder?

Dir ein schönes Wochenende

Das ist jetzt zwar fast vorbei, dennoch danke gleichfalls. :-)

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Guten Abend,

Du bleibst in der Funktion und führst selbst beim erfolgreichen Auslesen der externen Ressource mit einer Methode, die nicht als Letzte notiert ist, den Rest der Funktion mit den restlichen Methoden aus und überschreibst dabei die bereits ermittelten Werte.

Nein, dies passiert nicht, da mit empty($content) geprüft wird, ob dies notwendig ist; beachte empty(false) liefert true. Ich habe es nun nach Deinen Vorschlag erweitert und überall ein return hinzugefügt. In meiner Variante konnte, wenn bspw. curl zwar vorhanden ist aber aus irgendeinem Grund nicht geht, der nächste Zweig noch herhalten, dass geht jetzt nicht mehr.

Ich werde mir morgen erstmal den Code ziehen und die Änderungen ausprobieren.

Ja, das klingt gut.

Ich weiß nicht, wie das, gerade bei den beiden SQL-Dateien gemacht werden könnte.

Mit einer Datei: version.txt, wo die Version drin steht. Schließlich arbeitet die aktuelle Version ja auch mit $line = str_replace(' mlf2_', ' '.$_POST['table_prefix'], $line);. Warum also nicht noch einen Platzhalter nutzen für die aktuelle Release-Version?

das uns beim erstellen eines Releases als Checkliste dienen soll.

Sehr gute Idee. Ich weiß ja noch nicht, wie Du die Releases baust. Macht das Git allein oder machst Du das klassisch von Hand?

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo Milo

Die Diskussion führen wir besser in unserer Muttersprache, damit wir nicht allzusehr Gefahr laufen, uns misszuverstehen.

Du bleibst in der Funktion und führst selbst beim erfolgreichen Auslesen der externen Ressource mit einer Methode, die nicht als Letzte notiert ist, den Rest der Funktion mit den restlichen Methoden aus und überschreibst dabei die bereits ermittelten Werte.

Nein, dies passiert nicht, da mit empty($content) geprüft wird, ob dies notwendig ist; beachte empty(false) liefert true.

Ich habe mir nochmal den Code, in dem Status, in dem er war, als ich ihn kommentierte, angeschaut. Dabei habe ich auch meinen Denkfehler erkannt. Ich beschreibe mal, wie ich den Code nun verstehe. Anmerkungen sind als Kommentare notiert. Ich beginne nach der Deklarierung der Funktion. Wir sind also schon drinnen.

// Initialisierung der Variable mit dem Standardwert FALSE
$content = false;
// Abarbeitung des curl-Zweiges
if (function_exists('curl_init')) {
    // ...
    // Wenn in curl ein Fehler aufgetreten ist, setze $content explizit auf FALSE
    if(curl_errno($ch)) 
        $content = false;
    }
// Nächster Schritt: file_get_contents, Prüfung auf den Wert von $content mit empty().
// Die Prüfung schließt FALSE mit ein, ist mMn aber nicht sehr intuitiv.
// Dieses Rückgabewerts von empty war ich mir auch nicht bewusst, daher mein gestriger Einwurf.
 
// Sollte der von ini_get zurückgegebene Wert nicht gegen einen Vorgabewert geprüft werden?
// Laut Doku werden boolesche Werte von ini_get folgend zurückgegeben. on = 1, off = 0 oder '' [1]
if (empty($content) && @file_get_contents(__FILE__) && ini_get('allow_url_fopen')) {
    $content = @file_get_contents($url);
    // $content enthält nun einen String oder FALSE
    }
// Nächster Schritt: fsockopen
// Wiederum erfolgt die Prüfung mit empty
if (empty($content)) {
    // ...
    // Ist die folgende Vermischung der Notationen in Bezug auf die Lesbarkeit des Codes sinnvoll?
    if (!$fp)
        // Setze $content im Fehlerfall explizit auf FALSE
        $content = false;
    else {
        // ...
    }
// Gib, wenn $content leer oder FALSE ist, FALSE zurück, sonst den Inhalt von $content
if (empty($content))
    return false;
return $content;

Mein Denkfehler war also die Unkenntnis der Tatsache, dass FALSE in der Funktion empty als leerer Wert einer Variable gilt. Daher ist mein Vorschlag, jeweils an den Enden der Methodenblöcke die Funktion mit return $content; zu verlassen, natürlich hinfällig. Dass das sowieso nur nach dem erfolgreichen laden der Daten erfolgen sollte, sei mal dahingestellt. Das würde zwar funktional das gleiche Ergebnis wie deine Lösung erzielen, aber um einiges umständlicher sein.

Ich habe es nun nach Deinen Vorschlag erweitert und überall ein return hinzugefügt.

Wie gesagt, mein Blödsinn.

In meiner Variante konnte, wenn bspw. curl zwar vorhanden ist aber aus irgendeinem Grund nicht geht, der nächste Zweig noch herhalten, dass geht jetzt nicht mehr.

Eine Prüfung auf Erfolg hätte vorher aber schon stattgefunden haben sollen.

Ich weiß nicht, wie das, gerade bei den beiden SQL-Dateien gemacht werden könnte.

Mit einer Datei: version.txt, wo die Version drin steht. Schließlich arbeitet die aktuelle Version ja auch mit $line = str_replace(' mlf2_', ' '.$_POST['table_prefix'], $line);. Warum also nicht noch einen Platzhalter nutzen für die aktuelle Release-Version?

Stimmt, eine Datei namens VERSION oder RELEASE, die neben README.md, LICENSE und CHANGELOG steht, macht den Kohl auch nicht mehr fett.

das uns beim erstellen eines Releases als Checkliste dienen soll.

Sehr gute Idee. Ich weiß ja noch nicht, wie Du die Releases baust. Macht das Git allein oder machst Du das klassisch von Hand?

Neenee, das passiert schon von Hand. Einen Release schnürt wohl kein Versionssystem von sich aus. Nicht bei Skripten und nicht bei Kompilaten.

Tschö, Auge

[1] siehe Doku ini_get, Anmerkungen

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo,

Die Diskussion führen wir besser in unserer Muttersprache, damit wir nicht allzusehr Gefahr laufen, uns misszuverstehen.

Einverstanden - zumal wir im Moment wohl auch die einzigen aktiven Teilnehmer sind.

Ich habe es nun nach Deinen Vorschlag erweitert und überall ein return hinzugefügt.

Wie gesagt, mein Blödsinn.

Deine Version geht etwas schneller, da die wiederholte Prüfung nicht stattfinden wird, sondern die Methode direkt beendet wird. Ob die Millisekunden ins Gewicht fallen werden, sei mal dahin gestellt. Kurzum: Schau Dir bitte die PR an und modifiziere diese, wenn Du Verbesserungspotenzial siehst. Ich teste zwar die Sachen via XAMPP lokal und teilweise auch bei meinem Provider aber ...

Wenn ich Änderungen für nicht Review-würdig erachte, merge ich diese selbst. Bei allen anderen lasse ich es offen bis zur Freigabe oder der Aufforderung zum Mergen.

Stimmt, eine Datei namens VERSION oder RELEASE, die neben README.md, LICENSE und CHANGELOG steht, macht den Kohl auch nicht mehr fett.

Bin mir gerade nicht sicher, ob ein wenig Ironie mitschwingt. ;-) Um die Sache etwas zu entschärfen: Es ist nur ein Vorschlag.

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo

Ich habe es nun nach Deinen Vorschlag erweitert und überall ein return hinzugefügt.

Wie gesagt, mein Blödsinn.

Deine Version geht etwas schneller, da die wiederholte Prüfung nicht stattfinden wird, sondern die Methode direkt beendet wird.

Aber sie tut mit deinem nachgereichten Code nicht (return $content; am Ende jedes Blocks), was sie soll. Ohne eine zusätzliche Prüfung, ob die momentan benutzte Methode (welche in der momentanen Reihenfolge immer curl ist) zum Erfolg führte, wird die Funktion mit return $content; immer am Ende des curl-Blocks beendet. Es kommt nie zur Ausführung des weiteren Codes.

Deine von mir anfangs fehlinterpretierte Lösung, eingangs jedes Blocks eine Prüfung mit if (empty($content)) durchzuführen, womit der Block nur dann ausgeführt wird, wenn $content leer oder FALSE ist, ist um Längen besser, auch wenn sie mir auf den ersten Blick unverständlich war. Nach meiner Methode müsste jeder Block um eine Prüfung des Erfolgs ergänzt werden, bevor der Code return $content; ausgeführt wird. Das ist mMn unnötig umständlich.

Schau Dir bitte die PR an und modifiziere diese, wenn Du Verbesserungspotenzial siehst.

Mach ich be Bedarf nach dem Merge.

Ich teste zwar die Sachen via XAMPP lokal und teilweise auch bei meinem Provider aber wenn ich Änderungen für nicht Review-würdig erachte, merge ich diese selbst. Bei allen anderen lasse ich es offen bis zur Freigabe oder der Aufforderung zum Mergen.

Ist vermerkt.

Stimmt, eine Datei namens VERSION oder RELEASE, die neben README.md, LICENSE und CHANGELOG steht, macht den Kohl auch nicht mehr fett.

Bin mir gerade nicht sicher, ob ein wenig Ironie mitschwingt.

Ähhm, nö.

Um die Sache etwas zu entschärfen: Es ist nur ein Vorschlag.

Es ist ein mMn guter Vorschlag, weil er das Problem auf einfache Art löst. Es bedarf dann bei der Installation bzw. dem Update aber auch der Prüfung, ob die Datei vorhanden ist. Ganz ohne Heckmeck geht's also nicht. Die Datei kann ja nach der Installation oder dem Update ruhig vom Server gelöscht werden. Der Wert steht dann in der DB und kann aus dem Array $settings oder im Falle von JS aus dem HTML-Dokumentkopf heraus benutzt werden.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo Auge,

Es kommt nie zur Ausführung des weiteren Codes.

Doch, wenn curl nicht zur Verfügung steht, wir eine der anderen Varianten probiert. Dass aber nur am Rande, da ich die letzte Änderung wieder zurückgenommen habe.

Alles weitere dann, wenn Du Zeit zum Ansehen des Vorschlags gefunden hast.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo

Stimmt, eine Datei namens VERSION oder RELEASE, die neben README.md, LICENSE und CHANGELOG steht, macht den Kohl auch nicht mehr fett.

Ich hab' mir etwas Gedanken über die Datei VERSION (oder wie auch immer sie heißen soll) gemacht. Im Wurzelverzeichnis des Forums muss sie mMn nicht liegen. Die Dateien README.md, LICENSE und CHANGELOG, die genau dort sind, brauchen nicht auf ein Produktivsystem übertragen werden. Ihr Fehlen beeinträchtigt nicht die Funktion des Forums. Werden diese, weil sich jemand im voraus informiert hat, vor der Instanllation tatsächlich nicht übertragen, wird auch schnell die Datei VERSION vergessen – so kann ich mir zumindest vorstellen. Bei der Installation bzw. dem Update soll sie aber vonnöten sein, was von den Skripten geprüft werden muss und worauf natürlich die README.md und das Wiki hinweisen müssen.

Wie wäre es damit, sie stattdessen in das Verzeichnis config zu packen? Das hört sich einerseits irgendwie „richtig“ an und andererseits ist über die .htaccess der Zugriff auf den Verzeichnisinhalt über HTTP gesperrt. und da dort mit großer Wahrscheinlichkeit nur sehr wenige Admins überhaupt reinschauen, ist die Gefahr, dass die Datei vergessen wird, sehr gering.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Guten Abend,

Wie wäre es damit, sie stattdessen in das Verzeichnis config zu packen?

Kling gut. Ich hätte keine Einwände. ;-)

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo Milo

Ich hab mal etwas Code zusammengeschraubt und dabei folgende Erkenntnis gewonnen.

1. Tags wie bspw. "2.4beta1", "2.4.beta1", "2.4.beta" oder "2.4.b" werden mit einem einfachen Kleiner-Größer-Vergleich mit "2.4.0" als größer als die Letztere erkannt. Buchstaben werden also (von kleinen zu großen Werten) hinter Ziffern einsortiert. Wenn ich beim einfachen Code bleiben wollte (man ist ja faul ;-) ), hieße das, über die Vergabe der Versionsnummern nachzudenken, was du ja auch schon einmal angeregt hast oder, wohin ich tendiere, der Code muss zwischen den Stellen der Versionsnummer unterscheiden lernen.

2. Den Bohei mit Buchstaben in der Versionsnummer beiseite lassend, kann auf diese Weise einfach die versionsnummer aus den Skripten für die Installation und Update herausgelassen werden. Schön so. :-)

// check version:
if(!file_exists('../config/VERSION')) {
 $update['errors'][] = 'Error in line '.__LINE__.': Missing the file config/VERSION.';
}
$newVersion = trim(file_get_contents('../config/VERSION'));
if ($newVersion < $settings['version']) {
 $update['errors'][] = 'Error in line '.__LINE__.': The version you want to install (see string in config/VERSION) must be greater than the current installed version. Current version: '. htmlspecialchars($settings['version']) .', version you want to install: '.  htmlspecialchars($newVersion) .'.';
}
if(!in_array($settings['version'], $newVersion)) {
 $update['errors'][] = 'Error in line '.__LINE__.': This update file doesn\'t work with the current version.';
}

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi Auge,

es ist schön, dass Du dieses Problem nun auch erkennst. ;-) Ich hatte es beim Update-Checker auch und musste mir, nachdem Du ja nicht abzubringen warst, was einfallen lassen. ;-) Ich bin dann über die Zeit gegangen, weil die Versionierung ... sagen wir: unberechenbar war/ist.

Wie gesagt, ich versioniere bei neuen Projekten nur über das Datum. Bei alten Projekten habe ich eine Kombination aus Version und Build. Die version ist ein einfacher DOUBLE bspw. 3.5 und das Build ist ein Integer und wiederum das Datum. So komme ich in der Summe auf etwas wie 3.5.20160523. Im Code trenne ich beide Variablen, sodass ich auf beiden Variablen normale Operatoren anwenden kann, um zu ermitteln, ob eine neue Version vorliegt.

2. Den Bohei

Das Wort Bohei kannte ich gar nicht...

Buchstaben in der Versionsnummer beiseite lassend

Ja, dass würde vieles erleichtern. ;-)

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo Milo

es ist schön, dass Du dieses Problem nun auch erkennst.

Tja, in manche Falle muss man wohl selbst reinrennen. :-) Davon abgesehen lassen mich deine folgenden Ausführungen vermuten, dass wir "damals" aneinander vorbei geredet haben.

Ich hatte es beim Update-Checker auch und musste mir, nachdem Du ja nicht abzubringen warst, was einfallen lassen.

Hier ist wohl der Punkt, an dem ich dich falsch verstanden hatte. Da ich unsere alte Unterhaltung dazu gerade nicht wiederfinde, sei hier nochmal meine Haltung zusammengefasst.

1. Den Forenbetreibern gegenüber, also extern, die einschätzen können müssen, ob sie eine neue Version einspielen sollen oder nicht, brauchen wir eine Versionsbenennung, die einen Betastatus erkennen lässt.
2. Diese Benennung mit "beta0" – das ergibt sich aus meiner jetzt selbst erlangten Erfahrung – könnten wir intern durchaus weglassen, um uns nicht die Versionsnummerierung und deren Vergleich zu verkomplizieren.

Eine Versionsnummer kann, wenn wir uns auf ein konsistentes Schema geeinigt haben, ohne das Wort "Alpha" oder "Beta" in der Versionsnummer auskommen, im Namen jedoch weiter diese Ergänzung tragen.

Ich versioniere bei neuen Projekten nur über das Datum.

Das fände ich ein bisschen krass. Ich befürchte auch, dass das so manchen updatewilligen Forenbetreiber verwirren würde.

Bei alten Projekten habe ich eine Kombination aus Version und Build. Die version ist ein einfacher DOUBLE bspw. 3.5 und das Build ist ein Integer und wiederum das Datum. So komme ich in der Summe auf etwas wie 3.5.20160523.

Dieses Schema ist grundsätzlich auch auf eine Versionsnummer 2.3.7 oder 4.0.0 anwendbar. Vorteil deines Verfahrens ist die Anwesenheit des Zeitstempels, der als weiteres Vergleichsmerkmal herangezogen werden könnte. Probleme gäbe es nur in einem Fall wie bei den Versionen 2.3.6 und 2.3.6.1, wenn mir die gemachten Fehler sofort aufgefallen und beide Versionen am selben Tag veröffentlicht worden wären.

Wieso liegen eigentlich über zwei Wochen (18.07.2016 und 04.08.2016) zwischen den Versionen? In meiner Erinnerung und auch nach dem Datum des Threads kamen beide Versionen tatsächlich am selben Tag (04.08.2016) heraus. Bei Github wird wohl das Datum des getaggten Commits benutzt, auch wenn der schon Wochen vor dem Erstellen des Releases eingefügt wurde.

Verwirrend!

2. Den Bohei

Das Wort Bohei kannte ich gar nicht...

Mir war bis soeben nicht klar, dass es das Bohei ist. :-)

Buchstaben in der Versionsnummer beiseite lassend

Ja, dass würde vieles erleichtern.

Nunja, das habe ich mittlerweile eingesehen. Wir brauchen eine Nummerierung, deren Fortläufigkeit durch ihr Schema sichergestellt ist und die irgendwie an das bestehende Schema angefügt werden kann, um nicht die Hälfte der Forenbetreiber wegen Verwirrung zu verlieren. Das Schema vollständig zu verändern ist meiner Meinung nach die schlechteste Option.

Mit dem geplanten Sprung auf Version 2.4 bietet sich eine neue Festlegung an, ohne dabei allzuviel Scherben zu hinterlassen. Im Folgenden eine Aufzählung von Versionsschemata, die Prereleaseversionen (Alpha, Beta, auch Delta (RC)) berücksichtigen (oder auch nicht), die ich kenne. Der tatsächliche Release soll der 2.4-er werden.

1. Testversionen werden im 2.3.9.x-er Bereich vor die 2.4 einsortiert. Das könnten wir so kommunizieren, wir müssten nur höllisch aufpassen, nicht selbst durcheinander zu kommen.

2. Testversionen werden im 2.4.0.x-er Bereich einsortiert, der erste Stable Release des Zweiges wird als 2.4 (ohne Anhängsel) oder als 2.4.1 veröffentlicht. Weitere 2.4-er Versionen sind ausschließlich Fehlerbehebungen. Bei Einführung eines neuen Features wird die Versionsnummer auf 2.5 angehoben.

3. Testversionen werden mit ungeraden Nummern (z.B. 2.4.1.x) geführt, das dazugehörige Stable Release wäre dann die 2.4.2. testversionen des nächsten geplanten Releases liefen unter 2.4.3.x, der Stable dann 2.4.4.

4. Das von dir verwendete Schema mit dem angehängten Datum. Eine eindeutige Markierung als Testversion ist in der Versionsnummer nicht möglich. Im oben beschriebenen Fall 2.3.6 und 2.3.6.1 – so selten der auch eintreffen mag – hieße es aber wieder ein weiteres Merkmal (eine Ziffer) anzuhängen.

5. Statt des Datums kann auch eine Buildnummer, z.B. die eines SVN-Commits, an die Versionsnummer angehängt werden. Auch hier erfolgt dadurch keine Markierung als Testversion. Davon unabhängig steht uns mit Git eine solche fortlaufende Nummerierung nicht zur Verfügung. Stattdessen den Hash zu benutzen wäre möglich aber noch weitaus verwirrender als alle anderen beschriebenen Schemata.

6. und letztens. Hier und jetzt wäre die Möglichkeit einer nummerierten Liste schick gewesen.

Mir persönlich würde Punkt 1 oder 2 am besten gefallen. Gegenüber den installations- und updatewilligen Forenbetreibern sollte dennoch, wie ich ganz oben schon schrieb, ein Name, in dem z.B. "beta" enthalten ist, kommuniziert werden. Bei der Benutzung der Schemas 1 könnte dann aber auch zur Verwirrung führen, dass die Version 2.3.9.5 gleichzeitig die 2.4.beta5 ist.

So richtig perfekt für die gleichzeitige konsistente Nummerierung und verwirrungsfreie Kommunikation ist mMn keine der Lösungen. :-(

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo

Ich werde ein TODO schreiben, das uns beim erstellen eines Releases als Checkliste dienen soll.

Sehr gute Idee.

DONE

Es ist eine Stichpunktliste geworden, die bei Bedarf erweitert werden kann.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo,

DONE

Super, Danke!

Es ist eine Stichpunktliste geworden, die bei Bedarf erweitert werden kann.

Verstanden!

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo

der Code funktioniert bei mir auch nicht.

Da ich ebenfalls nicht so richtig weiterkomme, habe ich mir gedacht, einen großen Button vor/neben/unter/in das Adminmenü zu setzen, der mit …/latest auf das aktuelle Release zeigt. Die HTML-Struktur steht. Jetzt wollte ich die Zuweisung der Sprachstrings zu den Platzhaltern einbauen. Die für das Administrationshauptmenü finde ich aber auf Teufel-komm-raus nicht.

Kannst du mir sagen, wo ich die Zuweisungen finde? In der admin.inc.php, wo ich sie vermutet habe, scheinen sie nicht sein.

Danke und tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo,

der Code funktioniert bei mir auch nicht.

Gut, dass Du mich erinnerst! Ich habe meinen Provider gefragt, wie es mit PHP7 und deren Funktionalitäten so aussieht und warum mysqli nicht unterstützt wird wie auch HTTPS. In dem Zusammenhang ist mir aufgefallen, dass ich Dein Script unter PHP7 getestet hatte. Mit PHP5 funktioniert es, wie Du hier sehen kannst (ich lösche es ende der Woche wieder). Es ist eine 1zu1 Kopie von Deinem Code.

Da ich ebenfalls nicht so richtig weiterkomme, habe ich mir gedacht, einen großen Button vor/neben/unter/in das Adminmenü zu setzen, der mit …/latest auf das aktuelle Release zeigt. Die HTML-Struktur steht. Jetzt wollte ich die Zuweisung der Sprachstrings zu den Platzhaltern einbauen. Die für das Administrationshauptmenü finde ich aber auf Teufel-komm-raus nicht.

In den Sprachdateien sind diese unter [admin] zu finden bspw. user_administr_link. Diese werden ganz am Ende der admin.inc.tmpl ausgegeben ab Zeile 1080.

Kannst du mir sagen, wo ich die Zuweisungen finde? In der admin.inc.php, wo ich sie vermutet habe, scheinen sie nicht sein.

Wenn es sich um statischen Text aus den Sprachdateien handelt, werden die von SMARTY direkt gefunden über {#var_name#}. In der Sprachdatei muss es nun ein

var_name = My static label

geben.

Wenn es eine dynamische Variable ist, dann musst Du diese explizit setzen z.B. in der admin.inc.php über:

$smarty->assign('var_name', 'My dynamic label');

Im Template kannst Du nun - ähnlich wie in PHP - via $var_name den Inhalt anzeigen lassen.

Hilft Dir das weiter?

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo

Hilft Dir das weiter?

Ja.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo

Gut, dass Du mich erinnerst! Ich habe meinen Provider gefragt, wie es mit PHP7 und deren Funktionalitäten so aussieht und warum mysqli nicht unterstützt wird wie auch HTTPS. In dem Zusammenhang ist mir aufgefallen, dass ich Dein Script unter PHP7 getestet hatte. Mit PHP5 funktioniert es, wie Du hier sehen kannst (ich lösche es ende der Woche wieder). Es ist eine 1zu1 Kopie von Deinem Code.

Würdest du die auge.php bitte nach dem löschen von deinem Server lokal behalten? Ich möchte noch Tests fahren, die ich ja selbst nicht durchführen kann, bei dir nun aber doch möglich sein. Ich würde dir dann beizeiten neuen Code zukommen lassen.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi,

Würdest du die auge.php bitte nach dem löschen von deinem Server lokal behalten?

Ja, dass ist kein Problem. Schick mir oder poste die Daten und ich teste es aus.

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hi,

A problem with the Ajax-preview-bubble was reported.

I create a PR to fix this issue - tested in Operam, IE and Edge.

/Micha

P.S. Further feature: Define groups for users (and special categories).

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hi everybody.

I was recently given the admin role on some little forum using your engine.
The engine is really great and all the users love it, however they have some suggestions. Maybe I could report some of them as suggestions for the development.

Read/Unread posts
What if the read/unread status was (maybe optionally) determined on a timestamp? The timestamp might be stored either in a cookie, or on the server, bound to a user and maybe to a category. All posts (maybe in a category) newer than the stored timestamp, would be considered unread.
The forum would contain a 'Mark all as read' button, that would update the timestamp (maybe in a category) and refresh the view.
What do you think?
Ajax preview bubbles
Possibility to show the bubbles on hover over the post title.
Post title enhancements
Smilies, images and links in titles?

All the suggested features were based on the needs of the users. If they can be achieved without changing the engine, then sorry for bothering you in this post. Anyway, I hope some of them might be helpful.
Especially the displaying of read/unread posts based on a timestamp seems to me a valuable option.

Hello

The … users … have some suggestions. Maybe I could report some of them as suggestions for the development.

Let's go!

Read/Unread posts
What if the read/unread status was (maybe optionally) determined on a timestamp?
The forum would contain a 'Mark all as read' button, that would update the timestamp (maybe in a category) and refresh the view.
What do you think?

There is a half-way-implemented (?) feature to store the information about the users last 200 read entries. I have no clue, in wich way it works or was intended to work (I was given a bigger role in the development around three months ago).

IMHO it's not a satisfying solution to store only up to a fixed maximum of (here 200) entries in the list. On the other hand it would be a big additional data stack to store every ID of every by a registered user read posting for the whole future (= the time, the forum will exist).

Maybe it is a solution to store these information for – let's say – a half year or, if the setting auto_lock_old_threads is activated, until the thread is locked through the given time limit and is, so to speak, "archived".

This has to be discussed and I think, it needs a bit more time to implement it.

Ajax preview bubbles
Possibility to show the bubbles on hover over the post title.

I'm not willing to support that. Yes, it saves one click per entry but on the other hand it can – and I'm convinced it will – lead to many faulty operations, when users move the mouse cursor, pass over the titles of entries and opens numerous preview bubbles unintentionally.

Post title enhancements
Smilies, images and links in titles?

As the entries title is in many views a link in itself, links inside the entries titles are no option. I suspect, images in titles would likely break the layout, because users intends often to overact with the size of the images. Remains the smilies.

In the time of availability of unicode-smilies on many devices and in many operating systems and the fact, that the forum in itself works stable with unicode (UTF-8), it is already possible to use smilies in an entries title.
Attention: These are not the smilies you can insert into the entries body with the buttons!

I hope some of them might be helpful.

Yes, it is helpful, even it's partially rejected.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi, thanks for your extensive reply. Let me try to defend some points ;-)

There is a half-way-implemented (?) feature to store the information about the users last 200 read entries. I have no clue, in wich way it works or was intended to work...

As far as I observe the forum's behaviour, this works a bit inconsistently and depends on a browser. Let me suggest something, just as a wild idea to think of. You might not support the idea first, yet please give it a deeper thought.

First solution. Maybe not good for everyone (so it might be optional), but elegant and requires minimum coding and storing minimum information.
For each user you store only a timestamp (or alternatively just a few timestamps - one timestamp per category).
Posts that are older than the timestamp are rendered as read, the newer ones are rendered as unread.
The forum provides a toolbar button called "Mark all as read".
Clicking this button, user updates its timestamp (maybe category-based if a category is selected) to the current time. The button also re-renders the page, and all posts will be seen as read.

Second solution. Maybe a bit more flexible, but requires storing more data.
You store up to 200 timestamps per user. The 200 is for the 200 newest threads, not posts. The posts in the newest threads will be rendered read/unread basing on their thread's timestamp. The posts in the older threads will be rendered read/unead based on the maximum of all stored user's timestamps.
If one of the older threads receives a new post, it promotes to the list of 200 newest threads, degrading the current oldest one in the list.
The thread's timestamp gets increased when the user visits its posts (to the post creation time) or when the user opens the whole thread's view (to the current time).

This solution does not require to lock old threads. And in fact, I think that the arbitrary number of 200 can be significantly reduced without sacrificing the comfort of forum's use.

Anyway, I opt for the first solution. I was using a custom forum that behaved this way and it was very comfortable to use. Unluckily, this forum does not exist anymore, so I cannot show you how it behaved.

Possibility to show the bubbles on hover over the post title.

I'm not willing to support that. Yes, it saves one click per entry but on the other hand it can – and I'm convinced it will – lead to many faulty operations, when users move the mouse cursor, pass over the titles of entries and opens numerous preview bubbles unintentionally.

Before you say "no" permanently, please note that your current solution has already solved the problem. Notice that the old bubble disappears when the new is shown. The only change would consider the event that triggers showing the bubble. It seems that all the rest is already there and should work just perfect! It still might be an optional behaviour, in favour of the current forum users.

Attention: These are not the smilies you can insert into the entries body with the buttons!

Yes... that's exactly my point. This creates inconsistency. You write the subject and the body different, you see it different and it behaves different. Both entries might just as well behave the same and it would only increase flexibility, consistency and mean less if's in the code. Even hyperlinks inside subjects are possible (this part of the subject directs to a different href).

Thanks again, I hope I have convinced you in some way.

Please note that I don't want to encourage anybody to do the changes in the near future. I just wanted to share my visions, and this thread seemed a right place. Maybe some of the developers on our forum could actively contribute to your great work in the future, if you find it useful.

Best,
Glorifyday

Hi,

Ajax preview bubbles
Possibility to show the bubbles on hover over the post title.

I'm not willing to support that. Yes, it saves one click per entry but on the other hand it can – and I'm convinced it will – lead to many faulty operations, when users move the mouse cursor, pass over the titles of entries and opens numerous preview bubbles unintentionally.

We can/should add an option to the forum setting table to make this feature optional.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hello

Ajax preview bubbles
Possibility to show the bubbles on hover over the post title.

I'm not willing to support that. Yes, it saves one click per entry but on the other hand it can – and I'm convinced it will – lead to many faulty operations, when users move the mouse cursor, pass over the titles of entries and opens numerous preview bubbles unintentionally.

We can/should add an option to the forum setting table to make this feature optional.

I am still not convinced but I am not the project leader. So I will not hold back this feature, even if I personally think, that it is a misfeature. So here is my go for the merge with an extension to make it an optional feature. Let's merge your code after the final 2.3.7-release.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Please make it optional as I really hate popups on mouse over. Having to navigate your cursor around a page in a manner to not set off popups is not fun.

Hi,

Please make it optional.

Yes, of course. I extend the scope of the variable ajax_preview: off: ajax_preview=0, on click: ajax_preview=1 and on hover/on click: ajax_preview=2. The default case will not be 2.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hi glorifyday,

Ajax preview bubbles
Possibility to show the bubbles on hover over the post title.

I modified the JavaScript w.r.t. your suggestion. If you hover the speech-bubble-icon, the preview window will be shown. If you click the icon, the window will be pinned. I create a PR at github. Do you have an installed forum and can you check my modifications on your forum? Just replace the main.min.js and reload the forum.

And you give me some feedback?

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

I have an admin role on our forum, but no FS access.
I passed the info to the forum owner and I'll let you know how it works.

Thanks, it works exactly as you described.
I wonder, though, if this is a lot of work to show the bubble on mouse over the message subject, not over the bubble image?

Hi,

I wonder, though, if this is a lot of work to show the bubble on mouse over the message subject, not over the bubble image?

Yes, it is more complex than to use the icon.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Yes, it is more complex than to use the icon.

I found the icon code myself, but as for now, I have no idea where to look for if I would like to change to mouse over the subject (which behaviour is desired by our users because they are used to it). Anyway, it seems that the bubble mechanism is ready for that.

One thing more... do you find it reasonable to show the bubble icon only when a post has a non-empty body text? This condition is already checked somewhere in the code, to determine if the "no_text.png" icon should be shown.

Hi,

I found the icon code myself, but as for now, I have no idea where to look for if I would like to change to mouse over the subject

That's the point. ;-) Currently, the posting subject is not used by the JS. Thus, the bubble icon is an easy to use point of entry to implement this issue. We will add this issue within the version 2.4.x. The option is per default disabled and can be activate by setting ajax_preview=2.

One thing more... do you find it reasonable to show the bubble icon only when a post has a non-empty body text? This condition is already checked somewhere in the code, to determine if the "no_text.png" icon should be shown.

Good point, I add a feature request for version 2.4.x.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hi,

I found the icon code myself, but as for now, I have no idea where to look for if I would like to change to mouse over the subject

The subject is a li-element. This element will be selected by the javascript. Got to main.js (main.min.js) and look for the function var setPreviewBoxToMainPage = function(els). There is a loop:

for (var i=0; i<els.length; i++) {
 var el = els[i];
 var li = el.parentNode;
 // more code
}

The variable li is the element you are looking for. But I will not implement the hover support for the posting-title. You can/must implement this feature by your own.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

By the way:
may I ask you how you deal with the condensed code? Do you normally edit main.js and use some automatic tool to condense it to main.min.js?

Hi,

Do you normally edit main.js and use some automatic tool to condense it to main.min.js?

Yes, that's the way. Please note the comment in the main.js:

/***********************************************************************
* NOTICE: In order to reduce bandwidth usage, a minimized version of   *
* this script is used by default (main.min.js). Changes in this file   *
* do not have any effect unless it is loaded by the template           *
* (themes/[THEME FOLDER]/main.tpl).                                    *
* The minimized version was created with the YUI Compressor            *
* <http://developer.yahoo.com/yui/compressor/>.                        *
***********************************************************************/

A online-version of the YUI is: http://ganquan.info/yui/

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Sorry, I missed the comment.

...have you ever tried this?

https://sourceforge.net/projects/jsminnpp/

Hi,

...have you ever tried this?

We don't use it, because the compression rate is smaller (compared to YUI)

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

BTW, if this is not secret ;-) ... do you use any IDE for developing the forum?
Or just the vi? ;-)

Hi,

do you use any IDE for developing the forum?

No, I use Notepad++ for developing JavaScript (and PHP) and Eclipse for Java.

Or just the vi?

No ;-) I don't use Linux.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

...do you still have the main.js that was the uncompressed source for the modified main.min.js that you shared?

I thought I would be able to do the reverse engineering myself, but the compressor changes variable names what makes it a more difficult task.

...do you still have the main.js that was the uncompressed source for the modified main.min.js that you shared?

We have and provide the source of every file for every point in time since the developer(s) started to use Git. At the moment you can take the source of the file from the master branch. If you start changes from an older version you can open a menu from the button "branch: master" and select a branch or a tag (as stable declared version).

I thought I would be able to do the reverse engineering myself, but the compressor changes variable names what makes it a more difficult task.

Backup, backup, backup! ;-)

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

https://github.com/ilosuna/mylittleforum/pull/37/files

https://github.com/ilosuna/mylittleforum/blob/c06db8f041bf1cf7e6f724b6e428f545c7fa2114/js/main.js

I didn't know that this change was commited to the repo.

Hello

I didn't know that this change was commited to the repo.

IMHO it isn't commited. Because of a confusion Milo added it as the pull request, that you found, and additionally as part of pull request #38, that is not merged yet!

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

...but not merged to the trunk.
I just meant that it was available online, not only locally on Milo's machine ;-) .

Hi,

...do you still have the main.js that was the uncompressed source for the modified main.min.js that you shared?

This file is next to the min-Version!?

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

I'll try to check tomorrow.

You wouldn't believe how fast I got used to having the preview on mouse over ;-) .
It just rulezzzz ;-) .

Hi,

One thing more... do you find it reasonable to show the bubble icon only when a post has a non-empty body text? This condition is already checked somewhere in the code, to determine if the "no_text.png" icon should be shown.

A solution is in our PR for the upcoming version.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

After clicking "Refresh", the last order of threads is not preserved and resets to default. Is that intended?

What is "Refresh" exactly doing?

Hello

After clicking "Refresh", the last order of threads is not preserved and resets to default. Is that intended?

Hmm, we didn't change this part of the code. When there is a misbehaviour, it is there since long ago. On the other hand is this forum run by version 2.3.5 and here i can't reproduce the described misbehaviour. I also can't reproduce it in Milo's forum, which runs with the actual version 2.3.7.

What is "Refresh" exactly doing?

1. It reloads the main page.
2. It resets the browsers "list" of visited links for forum internal links (what's IMHO a misbehaviour by itself).

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

I can't reproduce the described misbehaviour. I also can't reproduce it in Milo's forum, which runs with the actual version 2.3.7.

I am not sure which version we have because I am not the forum owner. As an admin, I could only found the property "version" of value "2.3".

On the other hand, some sources were replaced by Milo's version... I don't know... maybe it had an unpredicted impact.

I'll try to survey our users if all of them have this problem. Maybe it's browser dependent?

I personally don't use the "Refresh", because of the point 2 below. After refreshing, all posts are unread, I find it quite distracting.

1. It reloads the main page.
2. It resets the browsers "list" of visited links for forum internal links (what's IMHO a misbehaviour by itself).

I think you didn't mention: 3. the "new" style modifier is cleared from posts and threads after "Refresh". This is why some of our users use the refresh anyway. After refreshing, the forum page contains no "new" threads and posts (visually: no red borders and arrows). I assume these users find it more readable to look at the icons than at the subjects. As I said, I don't belong to them.

Anyway, this behaviour of "Refresh" seems inconsistent to me. It clears "new" posts and threads? OK. But it also clears "read" style modifier and this is not intuitive.

From what you wrote a few days ago, I suspect that the list of read posts is kept somewhere and what is not in the list, is treated as unread. "Refresh" clears the list, right?
Maybe it should be done just the way round? To keep the list of unread posts and treat all the rest as read?

A few days ago I also considered some more solutions to this problem. I hope you found it useful in the future development.

Best,
Glorifyday

Hello

I can't reproduce the described misbehaviour. I also can't reproduce it in Milo's forum, which runs with the actual version 2.3.7.

I am not sure which version we have because I am not the forum owner. As an admin, I could only found the property "version" of value "2.3".

So I assume, that it should be the version 2.3.0 wich was released on september the 1st 2011. That said, I recommend an update, even it would be only about security issues.

On the other hand, some sources were replaced by Milo's version... I don't know... maybe it had an unpredicted impact.

Maybe it is. I know, that he uses not the standard theme. I don't know if he changed the forum script codewise.

I think you didn't mention: 3. the "new" style modifier is cleared from posts and threads after "Refresh".

Yes, that's point three. I subsumed it under point two (reset of the read status).

Anyway, this behaviour of "Refresh" seems inconsistent to me. It clears "new" posts and threads? OK. But it also clears "read" style modifier and this is not intuitive.

Yes.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

...and see what happens.

Personally, I think that the behaviour of read/unread posts is currently the most important issue of the forum, in terms of ergonomics. If the 'Refresh' is to be really useful, the effect of refreshing should be a view with all posts "read" and not "new". And I think most users will share my view.

Hallo

Personally, I think that the behaviour of read/unread posts is currently the most important issue of the forum, in terms of ergonomics.

Yes, it is a serious issue even it doesn't break the function of the forum software. But to read the word "ergonomics" from you, is for me a bit perplexing. ;-) Making links in entry titles possible, what leads to a text whereof different parts links to different pages or websites, is everything else but ergonomic. Users expect to have a link to the entry itself at that point.

If the 'Refresh' is to be really useful, the effect of refreshing should be a view with all posts "read" and not "new". And I think most users will share my view.

I strongly disagree. I expect to get an actualised state of the forum. Read entries should be marked as read, unread entries should stay unread, new entries that was created since the last (re)load of the page should also be shown as unread. Nothing to say against a function to mark all entries read, but that would not be a "refresh".

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Making links in entry titles possible, what leads to a text whereof different parts links to different pages or websites, is everything else but ergonomic. Users expect to have a link to the entry itself at that point.

But Auge, believe me, I saw it working in a forum used by hundreds of people and all of them were very satisfied with this behaviour. Unfortunately, the owner of the forum chose to close it without notice and a group of expats gathered in a new place, using the software that your team created, because it resembles the old forum a bit. I cannot show you the old forum, because it is closed, anyway the behaviour was very ergonomic and flexible. The users loved it.

I expect to get an actualised state of the forum. Read entries should be marked as read, unread entries should stay unread

I can agree with this. This would be OK.
I suspect, however, that this is programmatically difficult, so I proposed a different solution. You find it unacceptable, but I find it much more ergonomic than the current one. And I guess that it would mean only slight changes in a model and already implemented logic.

new entries that was created since the last (re)load of the page should also be shown as unread.

If they were already read before the refresh, this would not be intuitive.

Nothing to say against a function to mark all entries read, but that would not be a "refresh".

Anyway, it would be useful, at least as an "ersatz" for now.

Hi Auge,

Show views of all entries in a thread instead only of the opening entry in the table view (thread in a hidden category and thatswhy not linked).
Is this fixed?

I commit a fix for this issue cf. Count number of views of thread in table view.

Status 404 for images in a custom theme. It's probably an error of the theme creator, but maybe not.
Should be investigated.

I checked this issue on my local XAMPP installation. There was only one 404 error in install script. The favicon was missing. I commit a fix, cf. prevent 404 error. Other problems aren't reported for the current release.

An entry will furthermore reside in the feed even if it is removed from the forum.

I cannot reproduce this error.

A problem with the Ajax-preview-bubble was reported.
I for myself can't confirm the behaviour. On the other hand images should IMHO shrinked to a bit less of 100% of the width and/or height.

Fixed.

Someone wanted to have tab order for buttons, mainly in the posting form.

A fix is committed, cf. Change tab order.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hello

Wow! You was very diligent over the weekend.

An entry will furthermore reside in the feed even if it is removed from the forum.

I cannot reproduce this error.

I can reproduce it in two RSS-readers. If I see a spam entry in the RSS-feed, delete it in the forum and reload the RSS-feed afterwards. In the reader, the deleted entry will not be removed from the readers view. I have to delete it in the reader from the feed to remove it permanently.

Maybe only a cache-setting or an absent cache-controlling XML-element?

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi Auge,

Wow! You was very diligent over the weekend.

Thank you. I restructure my GIT project e.g. using a virtual host via XAMPP, developing system is equal to the local live-system etc. Therefore, I installed the new version (2.4) of the forum and saw some ... conflicts. ;-)

An entry will furthermore reside in the feed even if it is removed from the forum.

I cannot reproduce this error.

I can reproduce it in two RSS-readers. If I see a spam entry in the RSS-feed, delete it in the forum and reload the RSS-feed afterwards in the reader, the deleted entry will not be removed from the readers view. I have to delete it in the reader from the feed to remove it permanently.

I don't use a reader, I monitor the generated XML-files and these files are up-to-date. Thus, my question is: Is it a problem with our generated XML or is it a problem with the reader?

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hello

An entry will furthermore reside in the feed even if it is removed from the forum.

I cannot reproduce this error.

I can reproduce it in two RSS-readers. If I see a spam entry in the RSS-feed, delete it in the forum and reload the RSS-feed afterwards in the reader, the deleted entry will not be removed from the readers view. I have to delete it in the reader from the feed to remove it permanently.

I don't use a reader, I monitor the generated XML-files and these files are up-to-date.

So far, so good and known. There is a thread about the issue but I didn't find it.

Thus, my question is: Is it a problem with our generated XML or is it a problem with the reader?

I expect it to be a problem in and with the readers (caching?).

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi,

I expect it to be a problem in and with the readers (caching?).

The HTTP-header is:

HTTP/1.1 200 OK => 
Date => Mon, 17 Oct 2016 15:28:48 GMT
Server => Apache
X-Powered-By => PHP/5.3.26
Expires => Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control => no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma => no-cache
Set-Cookie => mlf2_last_visit=1476718128.1476718128; expires=Wed, 16-Nov-2016 15:28:48 GMT
Vary => Accept-Encoding
Connection => close
Content-Type => text/xml; charset=utf-8

No caching options are transmitted by the XML-file.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hello

While searching for some topics here and there, I found an old thread where an error occurs. The entry was submitted on march, the 11th 2014 and is, with forum language setted to German, shown as "Dienstag, 11. MÃ¤rz 2014". Is there anybody out there, who sees the same error?

http://mylittleforum.net/forum/index.php?id=7576

GET /forum/index.php?id=7576 HTTP/1.1
...

HTTP/1.1 200 OK
Date: Mon, 17 Oct 2016 16:04:30 GMT
Server: Apache
x-powered-by: PHP/5.3.26
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
Cache-Control: public, max-age=300
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 2726
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8

The with the generated page (!) sent headers seems to be fine. Maybe it's a misbehaviour of this installation?

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi,

The entry was submitted on march, the 11th 2014 and is, with forum language setted to German, shown as "Dienstag, 11. MÃ¤rz 2014". Is there anybody out there, who sees the same error?

and the solution. The word "März" is also correct in this posting.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo

Zur Info:

Wegen des überladens der Konfig-Daten einer Default-Sprache mit denen für eine ausgewählte Sprache, wobei die nicht übersetzten Strings aus der Default-Sprache behalten werden, habe ich ein Issue bei den Smarty-Entwicklern aufgemacht, nachdem ich mir in mehreren Suchmaschinen mit unterschiedlich formulierten Anfragen – natürlich erfolglos – einen Wolf gesucht habe.

Ich hoffe auf baldige Antwort.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo,

Ich hoffe auf baldige Antwort.

Ich hatte auch schon gesucht aber nur das hier gefunden. Das hilft uns aber nicht weiter, wenn ich es richtig verstehe. Wir wollen ja nicht alles in einer Daten haben...

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo Milo

Ich hatte auch schon gesucht aber nur das hier gefunden. Das hilft uns aber nicht weiter, wenn ich es richtig verstehe. Wir wollen ja nicht alles in einer Daten haben...

Nein und bloß nicht!

Alle Sprachen in einer Datei zu halten würde schon wegen der unterschiedlichen Quellen, aus denen die Übersetzungen stammen, nicht funktionieren. Das wäre ein heilloses Durcheinander. Dass eventuell noch Probleme mit den gleichnamigen Sektionen in den verschiedenen Sprachen hinzukämen, wäre an der Stelle nur noch das Sahnehäubchen eines Problems.

Keine Ahnung, ob eine Verschachtelung, wie die folgende, überhaupt funktioneren würde. Ich habe zumindest keinen Hinweis darauf gefunden.

[en]
  [default]
    foo = hassel
    bar = stool
  [admin]
    foo = diggeldoo
    brutzel = roast
[es]
  [default]
    foo = hossel
    bar = el taburete
  [admin]
    foo = diggeldos
    brutzel = freír algo
[de]
  [default]
    foo = hussel
    bar = hocker
  [admin]
    foo = diggeldu
    brutzel = Braten

Aber wie du schon schriebst, das steht nicht zur Debatte.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo,

Ich hatte auch schon gesucht aber nur das hier gefunden.

Ich habe nach weiteren Recherchen diesen Thread im Smarty-Forum gefunden. besonders der Satz „Like templates, config_loaf will honor the resource plugin system.“ hat mich nicht mehr losgelassen. Was hindert mich daran, mit einem PHP-Skript das gewünschte Array zusammenzusetzen und an configLoad zu übergeben?

Jetziger Zustand (index.php ab Zeile #46):

if(isset($_SESSION[$settings['session_prefix'].'usersettings']['language']) && file_exists(LANG_DIR.'/'.$_SESSION[$settings['session_prefix'].'usersettings']['language']))
 {
  $language_file = $_SESSION[$settings['session_prefix'].'usersettings']['language'];
 }
else
 {
  $language_file = $settings['language_file'];
 }
$smarty->assign('language_file', $language_file);
$smarty->configLoad($language_file, 'default');
$lang = $smarty->getConfigVars();

Entwurf:

$smarty->assign('language_file', $language_file); // <=
// Keine Ahnung, was ich mit der vorangehenden Zeile mache
// Ohne die Zeile gibt's eine Fehlermeldung
// Wpozu braucht Smarty überhaupt den Dateinamen, wenn die Daten mit der nächsten Zeile übergeben werden?
 
$smarty->configLoad('skript.php', 'default');
$lang = $smarty->getConfigVars();

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi,

[code=php]$smarty->assign('language_file', $language_file); // <=

Hier wird nur eine Variable angelegt, auf die man im Template dann zugreifen kann. Zum Laden der Datei ist die nicht notwendig.

// Keine Ahnung, was ich mit der vorangehenden Zeile mache
// Ohne die Zeile gibt's eine Fehlermeldung

Aber an einer anderen Stelle, wo versucht wird, auf diese Variable zuzugreifen, oder?

// Wozu braucht Smarty überhaupt den Dateinamen, wenn die Daten mit der nächsten Zeile übergeben werden?

Gar nicht aber Alex hat sie irgendwo noch mal verbaut - würde ich meinen. Für configLoad ist es jedenfalls nicht notwendig.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo

$smarty->assign('language_file', $language_file);

Hier wird nur eine Variable angelegt, auf die man im Template dann zugreifen kann.

Danke für die Klarstellung.

// Keine Ahnung, was ich mit der vorangehenden Zeile mache
// Ohne die Zeile gibt's eine Fehlermeldung

Aber an einer anderen Stelle, wo versucht wird, auf diese Variable zuzugreifen, oder?

Ja, in irgendeiner Datei des Smarty-Plugins. Die Meldung habe ich mir nicht rauskopiert. Wenn du, entsprechendes Interesse vorausgesetzt, die Zeile in der index.php auskommentierst und das Forum neu lädst, kannst du sie sehen.

Für configLoad ist es jedenfalls nicht notwendig.

Soweit hatte mich das Studium der Doku auch gebracht und dann war Schluss. Das ist, wie gegen eine Wand zu laufen. :-(

Davon ab ist mir in einer nächtlichen Grübelsitzung folgendes durch den Kopf gegangen. Die von mir angeregte Zusammenführung der Arrays kann sich als eine Performanzbremse par excellence herausstellen. So, wie ich das angeregt habe, wird die ja bei jedem Request einer Forumsseite ausgeführt. Das fällt, wenn's nach mir geht, aus.

Ich habe beim grübeln aber zwei neue Ideen gehabt.

Die Sprachdateien sind in einem Format abgespeichert, dass den INI-Format entspricht. Die Schlüssel-Wert-Paare lassen sich in Arrays einlesen und deren Schlüssel widerum lassen sich vergleichen und die Unterschiede ermitteln. Wie dabei mit mehrdimensionalen Arrays umzugehen ist, muss ich noch ausprobieren.

Ich kann nun dem Admin in der Sidebar der Admin-Übersicht anzeigen, dass es soundsoviele nicht übersetzte Strings gibt und ihn für ein HowTo zur Übersetzung auf die Dokumentation verweisen. Wenn ich ganz generös bin, kann ich noch einen Link zu einer Auflistung der Unterschiede beifügen.

Allerdings halte ich einen Verweis auf ein Diff-Programm wie z.B. WinMerge (Windows) oder Merge (Linux) für ausreichend. Für diese beiden Programme kann ich bestätigen, dass sie die unmittelbare Bearbeitung von Dateien erlauben sowie zwischen fehlenden und teilweise gleichen Zeilen unterscheiden können. Der letzte Fall ist in den Sprachdateien der Normalzustand (identische Schlüssel, unterschiedliche Texte), fehlende Zeilen wären jene Stellen, an denen die nicht übersetzten Strings hinkommen.

Als Alternative kann auch jeder nicht übersetzte String in der Default-Sprache (englisch) in jede Sprachdatei eingefügt werden. Die Strings werden auffallen und es wird Übersetzungen geben.

Die Übersetzungen werden uns hoffentlich hier oder auf Github angeboten und können dann eingepflegt werden. Auf der Ausgabeseite, an der ich gestern herumprobiert habe, würde sich in Sachen Code in beiden Fällen nichts ändern.

Gefällt dir (zumindest) eine der Ideen? Wenn ja, welche ist es?

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Guten morgen,

Ja, in irgendeiner Datei des Smarty-Plugins. Die Meldung habe ich mir nicht rauskopiert. Wenn du, entsprechendes Interesse vorausgesetzt, die Zeile in der index.php auskommentierst und das Forum neu lädst, kannst du sie sehen.

Das glaube ich auch so. Ein Blick in die main.tpl Datei reicht hier schon aus. In der ersten Zeile wird die angelegte Variable vom Template ausgelesen:

{config_load file=$language_file section="general"}

Ich kann mir also vorstellen was passiert, wenn diese nicht explizit vorhanden ist. ;-)

Das fällt, wenn's nach mir geht, aus.

Ja, stimmt. Eine ähnliche Überlegung hatte ich auch bei der Versionsanzeige im Adminbereich. Hier hatte ich erst überlegt, ob man die Anfrage an den github-Server nur einmal am Tag macht und in einer DB-Tabelle abspeichert. Dies sollte verhindern, dass permanent der Feed ausgelesen wird. Kurzum: Ich kann Deine Bedenken, die hier noch viel gravierender sein müssten, verstehen.

Als Alternative kann auch jeder nicht übersetzte String in der Default-Sprache (englisch) in jede Sprachdatei eingefügt werden. Die Strings werden auffallen und es wird Übersetzungen geben.

Das wäre nach meinem Dafürhalten die beste Lösung, da hier der Kreis an Leuten, die das Problem sehen, noch größer ist. Jeder User wird erkennen, dass bestimmte Phrasen nicht in seiner Muttersprache vorliegen und nicht nur der jeweilige Admin.

In Java gibt es sogenannte ResourceBundle. Hier legt man properties-Files an (Vergleichbar mit einer ini) für die Default-Sprache z.B. foo.properties und für jede Sprache, die man anbieten kann zusätzlich eine mit Locale-Sufix. Für Deutschland wäre es dann foo_de.properties, Emgland foo_en.properties, Frankreich foo_fr.properties usw. In Abhängigkeit der Default-Locale wird dann automatisch die richtige Datei geladen. Zeichenketten, die nicht vorhanden sind, werden dann aus der foo.properties geholt, sodass man einmal eine Rückfallebene hat (wenn neue Labels hinzukommen aber man bspw. kein französisch spricht) und zum anderen auch Ressourcen spart, wenn bestimmte Begriffe in Sprachen identisch heißen. Kurzum: Es wäre cool, wenn SMARTY das auch könnte. Hat Deine Anfrage im Forum dort etwas gebracht?

Gefällt dir (zumindest) eine der Ideen? Wenn ja, welche ist es?

Deine zweite finde ich gut, da ja in diesem Fall dem User zumindest etwas angezeigt wird. Bedenke: Wenn der Schlüssel nicht vorhanden ist, sieht der User auch nichts. Insofern sollte mind. der Default-String vorhanden sein.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo

Das fällt, wenn's nach mir geht, aus.

Ja, stimmt. Eine ähnliche Überlegung hatte ich auch bei der Versionsanzeige im Adminbereich. Hier hatte ich erst überlegt, ob man die Anfrage an den github-Server nur einmal am Tag macht und in einer DB-Tabelle abspeichert. Dies sollte verhindern, dass permanent der Feed ausgelesen wird.

Du bist mit dieser Überlegung nicht allein. :-)

Meine Idee: Wie wäre es mit einem Eintrag des Datums der letzten Versionsabfrage in der Settings-Tabelle? Das Datum wird beim laden der Admin-Übersicht abgefragt und nur, wenn seitdem X Zeit vergangen ist, eine neue Abfrage des Feeds durchgeführt.

X = 12h, X = 24h oder X = 36h (oder irgendwie so)

Als Alternative kann auch jeder nicht übersetzte String in der Default-Sprache (englisch) in jede Sprachdatei eingefügt werden. Die Strings werden auffallen und es wird Übersetzungen geben.

Das wäre nach meinem Dafürhalten die beste Lösung ...

Dann ist das beschlossene Sache. Diese Umsetzung vereinfacht zudem die Übersetzung, weil eine Suche mit dem String in der fraglichen Sprachdatei direkt zum zu übersetzenden Text führt.

In Java gibt es sogenannte ResourceBundle. Hier legt man properties-Files an (Vergleichbar mit einer ini) für die Default-Sprache z.B. foo.properties und für jede Sprache, die man anbieten kann zusätzlich eine mit Locale-Suffix.

In der 1-er Version von MLF ist das einfach zu lösen gewesen. Dort liegen die Sprachdateien als PHP-Arrays vor, womit das überschreiben vorhandener Einträge über die identischen Schlüssel simpel vonstatten geht. Zudem habe ich noch einen Debug-Modus eingebaut, der für jede eingefügte Zeichenkette deren Herkunft und den Schlüssel hinter dem Text oder, falls nötig, im Title-Attribut des zugehörigen Elements einträgt.

Damit lassen sich die noch nicht übersetzten Strings einfach finden, zuordnen und den Kontext des Textes interpretieren.

Hat Deine Anfrage im Forum dort etwas gebracht?

Wieso Forum? Ich hab's mit einem Github-Issue gleich ganz oben, bei den Entwicklern, angebunden. Eine Antwort ist auch schon gekommen. Weitere Tests folgen, wobei letztendlich die statische Einbindung der Texte in der Default-Sprache zum Einsatz kommen wird (KISS, Performanz).

Ich will's nun aber mal wissen. :-)

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo,

Meine Idee: Wie wäre es mit einem Eintrag des Datums der letzten Versionsabfrage in der Settings-Tabelle? Das Datum wird beim laden der Admin-Übersicht abgefragt und nur, wenn seitdem X Zeit vergangen ist, eine neue Abfrage des Feeds durchgeführt.

Genau. Man würde dann aber zwei Einträge benötigen. Einen für die Abfragezeit und einen für die aktuelle Version. Aber grundsätzlich entspricht dies auch der von mir favorisierten Lösung. ;-)

Wieso Forum? Ich hab's mit einem Github-Issue gleich ganz oben, bei den Entwicklern, angebunden. Eine Antwort ist auch schon gekommen. Weitere Tests folgen, wobei letztendlich die statische Einbindung der Texte in der Default-Sprache zum Einsatz kommen wird (KISS, Performanz).

Ah, okay. Wusste ich nicht. Die dort beschriebene Lösung

$smarty->setConfigOverwrite(true);  // is default 
$smarty->configLoad('default.conf',....');
$smarty->configLoad('selected.conf', '.....');
$smarty->display(...);

hilft uns theoretisch weiter. Du müsstest aber zusätzlich(!) beide Dateien auch als Variable vorhalten und in jedem einzelnen Template zunächst die Default-Variante und dann die spezialisierte Variante aufrufen, damit tatsächlich aus beiden die Schnittmenge gebildet werden kann.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo

Meine Idee: Wie wäre es mit einem Eintrag des Datums der letzten Versionsabfrage in der Settings-Tabelle? ...

Genau. Man würde dann aber zwei Einträge benötigen. Einen für die Abfragezeit und einen für die aktuelle Version.

Ja, natürlich. :-)

Aber grundsätzlich entspricht dies auch der von mir favorisierten Lösung.

Dabei geht mir folgendes durch den Kopf. Alles, was in der Settings-Tabelle steht, wird vom Autor(enteam) willkürlich in "gehört zu den wichtigen Einstellungen" mit expliziten Formularelementen auf der ersten Einstellungsseite und den anderen, die nur über die erweiterten Einstellungen als Text oder Zahlenwert zugänglich sind, eingeteilt.

Das finde ich – gelinde gesagt – nicht so prickelnd. Einerseits impliziert die getroffene Auswahl eine Wichtigkeit oder Unwichtigkeit, die nicht zutrifft (Poster in diesem Forum fallen ja gelegentlich aus allen Wolken, wenn man sie auf die erweiterten Einstellungen hinweist) und andererseits erschließen sich die möglichen Eingaben im Formular mit den erweiterten Einstellungen oft nicht (Zahlenwerte? Wenn ja, in welchem Bereich? Text mit welcher Maximallänge?).

In MLF1 habe ich die Tabellenstruktur folgendermaßen erweitert (aus der install.php).

CREATE TABLE forum_settings (
 name VARCHAR(255) NOT NULL DEFAULT '',
 VALUE VARCHAR(255) NOT NULL DEFAULT '',
 TYPE VARCHAR(30) NOT NULL DEFAULT '',
 poss_values VARCHAR(160) NOT NULL DEFAULT '',
 standard VARCHAR(80) NOT NULL DEFAULT '',
 cat VARCHAR(20) NOT NULL DEFAULT '',
 UNIQUE KEY setting (name)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8

Die Felder name und value existierten schon und tun dies auch in MLF2. Das Feld cat gruppiert die Einstellungen in Kategorien, die HTML-seitig als Reiter dargestellt wird, auf. Das Feld type gibt an, welchen Typ das Eingabeformat und somit auch das zu verwendende Formularelement hat. Zusammen mit den bei Bedarf definierten möglichen Werten in poss_values ergibt sich z.B. für den Typ "array" ein <select> mit den möglichen Werten in den <option>s und aus den Typen "string" bzw. "integer" unterschiedlich lange Eingabefelder.

Vergleiche dazu auch den Code in admin.php, ab Zeile #2361. Das sollte eine Überlegung wert sein.

$smarty->setConfigOverwrite(true);  // is default 
$smarty->configLoad('default.conf',....');
$smarty->configLoad('selected.conf', '.....');
$smarty->display(...);
hilft uns theoretisch weiter. Du müsstest aber zusätzlich(!) beide Dateien auch als Variable vorhalten und in jedem einzelnen Template zunächst die Default-Variante und dann die spezialisierte Variante aufrufen, damit tatsächlich aus beiden die Schnittmenge gebildet werden kann.

Meine Meinung: Nö, das fetzt nicht. (ist mMn unnötig kompliziert)

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo,

Genau. Man würde dann aber zwei Einträge benötigen. Einen für die Abfragezeit und einen für die aktuelle Version.

Ja, natürlich.

Vielleicht ist die Setting-Tabelle hier eher eine unglückliche Wahl. Immerhin ist dies ja keine Einstellung, die der Nutzer auch anpassen kann. Wäre eine eigene Tabelle daher nicht ggf. die bessere/sauberere Variante?

Vergleiche dazu auch den Code in admin.php, ab Zeile #2361. Das sollte eine Überlegung wert sein.

Ja, sieht gut aus. Kannst Du gern integrieren.

Meine Meinung: Nö, das fetzt nicht. (ist mMn unnötig kompliziert)

Naja, es ist sicher nicht die schönste Arbeit aber kompliziert? Mit Suchen und Ersetzen müsste man ja nur nach folgendem Aufruf suchen

{config_load file=$language_file section="general"}

und davor ein

{config_load file=$default_language_file section="general"}

einfügen (ggf. für die anderen Sections ergänzen). Ich denke, der Aufwand ist überschaubar und in den einzelnen Sprachdateien würde keine Mischung von Übersetzungen auftreten. Meinst Du nicht, dies wäre langfristig eine Erleichterung, wenn wir nicht in jeder einzelnen lang-Datei die englische Version noch einpflegen müssen?

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo

Genau. Man würde dann aber zwei Einträge benötigen. Einen für die Abfragezeit und einen für die aktuelle Version.

Ja, natürlich.

Vielleicht ist die Setting-Tabelle hier eher eine unglückliche Wahl. Immerhin ist dies ja keine Einstellung, die der Nutzer auch anpassen kann.

Das gilt dann aber auch für "Einstellungen" wie z.B. last_action.

Wäre eine eigene Tabelle daher nicht ggf. die bessere/sauberere Variante?

Grundsätzlich ja. Da last_action aber auch in der Einstellungstabelle liegt, dachte ich mir, die gefundene Version und den Zeitpunkt der letzten Abfrage ebenfalls dorthin zu verfrachten.

Vergleiche dazu auch den Code in admin.php, ab Zeile #2361. Das sollte eine Überlegung wert sein.

Ja, sieht gut aus. Kannst Du gern integrieren.

Meine Meinung: Nö, das fetzt nicht. (ist mMn unnötig kompliziert)

Naja, es ist sicher nicht die schönste Arbeit aber kompliziert?

Hmm, falsch ausgedrückt. Es ist keineswegs kompliziert, den Code anzupassen. Ohne weiteren Code ergibt sich aber eine bei jedem Aufruf wiederkehrende Ausführung der Einbindung zweier Konfigurationsdateien (Sprachdateien). Die ist im Gegensatz zu der hartkodierten Einfügung der Texte der Standardsprache in jede Sprachdatei in der Ausführung unnötig kompliziert und ressourcenfressend.

Mit Suchen und Ersetzen müsste man ja nur ...

Ich denke, der Aufwand ist überschaubar und in den einzelnen Sprachdateien würde keine Mischung von Übersetzungen auftreten.

Klar, unbestritten. Arbeitstechnisch ist, wie oben schon gesagt, das kaum Aufwand und auch die Mischung der Sprachen entfiele. Andererseits stellt genau diese Mischung der Sprachen neben der Präsenz aller Schlüssel-Wert-Paare in den Sprachdateien auch sicher, dass diese bei Übersetzungen in den richtigen Abschnitten stecken. Auch wenn die meisten Übersetzungswilligen die Struktur durchschauen werden, wird es einzelne geben, die damit nicht zurecht kommen und hier (IMHO vermeidbare) Fragen stellen.

Meinst Du nicht, dies wäre langfristig eine Erleichterung, wenn wir nicht in jeder einzelnen lang-Datei die englische Version noch einpflegen müssen?

Das ist auch nur "suchen und ersetzen". :-)

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo,

Das gilt dann aber auch für "Einstellungen" wie z.B. last_action.

Du meinst sicher "last_changes" aber ja, die gehört hier auch nicht wirklich hin.

Meinst Du nicht, dies wäre langfristig eine Erleichterung, wenn wir nicht in jeder einzelnen lang-Datei die englische Version noch einpflegen müssen?

Das ist auch nur "suchen und ersetzen".

Korrekt, aber mit dem Unterschied, dies _jedes mal_ machen zu müssen. Die Alternative wäre eine _einmalige_ Änderung. :-D

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo,

Das gilt dann aber auch für "Einstellungen" wie z.B. last_action.

Du meinst sicher "last_changes" aber ja, die gehört hier auch nicht wirklich hin.

Nö, meinte ich nicht. </rumsuch> Ah, ja! Ich meinte next_daily_actions, welches auch einen Zeitstempel speichert. Die Einstellung folgt also dem selben Prinzip wie das von dir genannte last_changes.

Meinst Du nicht, dies wäre langfristig eine Erleichterung, wenn wir nicht in jeder einzelnen lang-Datei die englische Version noch einpflegen müssen?

Das ist auch nur "suchen und ersetzen".

Korrekt, aber mit dem Unterschied, dies _jedes mal_ machen zu müssen. Die Alternative wäre eine _einmalige_ Änderung.

Korrekt. Nun wäre nur abzuwägen, ob wir als Developer das jeweils einmalig bei jeder Änderung an den Sprachdateien machen oder ob wir uns diese Arbeit sparen und die Aufgabe der Forensoftware übergeben, die das in jeder Installation bei jedem Aufruf macht. Ich kann den Einfluss auf die allgemeine Performanz nicht einschätzen, glaube aber, dass ich mir keinen Zacken aus der Krone breche, wenn ich einen neuen String in momentan </nachguck> 11 Dateien übertrage und dabei gleich eine Übersetzung mitliefere.

Was ist, wenn dieser Automatismus aufgenscheinlich keinen Einfluss auf die Performanz zeigt, dies aber in Kombination mit weiteren Automatismen, die vielleicht überhaupt noch nicht vorhanden sind, eben doch tut. Wer weiß, was für Blödsinn™ uns noch einfallen mag.

Außerdem habe ich am Wochenende schon damit angefangen, die Sprachdateien nach Inkonsistenzen abzugrasen. Den Aufwand umsonst betrieben zu haben, ließe mich ein wenig betrübt zurück. ;-)

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo,

Außerdem habe ich am Wochenende schon damit angefangen,

Vielleicht solltest Du diese Details nicht so im Verborgenen halten. ;-)

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo

Außerdem habe ich am Wochenende schon damit angefangen,

Vielleicht solltest Du diese Details nicht so im Verborgenen halten.

done! :-)

Du hast natürlich recht. Eine frühere Ansage hätte zur Klarheit beigetragen. Das ist das Doofe, wenn es aussieht, als wäre man zu einer Entscheidung gekommen und dann kommen neue Argumente ins Spiel.

Lass' uns mal vorerst bei der händischen Pflege der Sprachdateien bleiben. Wir können später immer noch über eine elegantere Lösung diskutieren. Die Vorgabe der Schlüssel mit den Werten in der Default-Sprache in jeder Sprachdatei ist eine simple, funktionierende Lösung, die wir ohne weiteren Aufwand bereits haben.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Guten Abend,

Lass' uns mal vorerst bei der händischen Pflege der Sprachdateien bleiben.

Ja, kein Problem!

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo

Ich brauche mal gedankliche Unterstützung in meiner Muttersprache bezüglich des Codes für den gelesen-Status der Beiträge.

Soweit ich das verstehe, wird beim Login die Spalte userdata_table.entries_read eingelesen und über den Umweg über $usersettings['read'] in das Array $read überführt, dessen Inhalt wiederum sowohl in der Session als auch in einem Cookie abgelegt wird. Wenn ein Beitrag geöffnet wird, wird seine ID im Cookie und, wenn der entsprechende Funktionsparameter gesetzt ist, das gesamte, nun ergänzte Array in der Datenbank gespeichert.

Wenn es nun zukünftig für jeden von einem registrierten und angemeldeten Benutzer gelesenen Beitrag einen eigenen Datensatz gibt, ist der bisherige Weg doch ein unnötiger Umweg, oder? Die Information, dass ein bestimmter Beitrag vom gegenwärtig angemeldeten Benutzer bereits gelesen wurde, liegt pro Benutzer und Beitrag einmalig vor (1:1 gegenüber den Beiträgen).

Das heißt, diese Information kann – z.B. mit einem Subquery, der je nach Status 0 oder 1 zurückgibt oder über einen Join – direkt an das Posting gebunden werden. Gebraucht wird die Info dann, wenn ein Beitrag oder ein Thread(baum) anzeigt wird und gelesene Beiträge dort als gelesen hervorgehoben werden soll(en). Das Array in der Session oder in einem Cookie zu speichern und bei jedem Aufruf hin und her zu übertragen, ist, wenn ich nichts vergessen habe, unnütz.

Ich zermartere mir nun schon seit ein paar Tagen über diese Abwägung den Bregen. Einfach die Lese- und Schreibfunktionen umzubauen, ist einfach. Da ich aber Bauchschmerzen mit dem momentanen Konzept habe, ist mir der Umbau etwas ungeheuer. Nicht, dass ich da etwas vergesse.

Sind da noch Aspekte, die hier offensichtlich fehlen?

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Guten morgen,

Wenn es nun zukünftig für jeden von einem registrierten und angemeldeten Benutzer gelesenen Beitrag einen eigenen Datensatz gibt, ist der bisherige Weg doch ein unnötiger Umweg, oder?

Ja, das würde ich auch meinen.

Das heißt, diese Information kann – z.B. mit einem Subquery, der je nach Status 0 oder 1 zurückgibt oder über einen Join – direkt an das Posting gebunden werden.

Genau. Über ein JOIN würde ich es lösen, da das vermutlich schnelle ist, als die doppelte Abfrage.

Das Array in der Session oder in einem Cookie zu speichern und bei jedem Aufruf hin und her zu übertragen, ist, wenn ich nichts vergessen habe, unnütz.

Ja, dies würde ich im Moment auch so sehen. Die CSS-Klassen usw. werden durch die Daten aus der DB-Tabelle gesetzt, sodass der Wert in der Session nicht mehr stehen muss.

Nicht, dass ich da etwas vergesse.

Ich kann gegenwärtig keinen Denkfehler erkennen. Es wäre auch meine Vorgehensweise gewesen.

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo Milo

Danke für deine Unterstützung.

Wenn du schon mal "da" bist. Kannst du bitte meine Fragen zu deinem PR #76 beantworten. Es geht um den Tabellentyp, die Sortierungsangabe (Collation) und deine Code-Änderungen wegen meines Fixes (Spalte id weg), bei der du offensichtlich die install.sql vergessen hast. :-)

Zur Collation sei gesagt, dass die phpMyAdmin-Installation meines Hosters eine entsprechende Angabe wegoptimiert. Das mag aber auf die konkrete Installation in Kombination mit der dahinter liegenden MySQL-Installation ankommen.

Erstelle mal bitte testweise die Tabelle mit Angabe der Collation und lasse phpMyAdmin ein CREATE-Statement generieren (bei mir über den Menüpunkt "Exportieren"). Bei mir findet sich im erstellten Statement kein Hinweis auf die Collation, wohl, weil es kein Feld irgendeines Text-Typs (char, varchar, text) gibt.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo Milo

Danke für deine Unterstützung.

Wenn du schon mal "da" bist. Kannst du bitte meine Fragen zu deinem PR #76 beantworten.

Ich habe es versucht. Ich sehe keinen Grund für die UNIQUE-Bedingung. Ein Datensatz ist konsistent, wenn er eine POSTING-ID und eine USER-ID besitzt - ergo ist das der PRIMARY KEY. Das hatte ich in der BOOKMAR-Tabelle auch so vorgesehen, bis ich die Signatur der move_item-Funktion gesehen habe, die einen ID erfordert.

ENGINE/COLLATE

Diese Angaben übernehme ich von den Tabellendefinitionen der bereits vorhanden Tabellen.

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo Milo

Danke für deine Unterstützung.

Wenn du schon mal "da" bist. Kannst du bitte meine Fragen zu deinem PR #76 beantworten.

Ich sehe keinen Grund für die UNIQUE-Bedingung. Ein Datensatz ist konsistent, wenn er eine POSTING-ID und eine USER-ID besitzt - ergo ist das der PRIMARY KEY.

Gut, der UNIQUE INDEX entspricht, bezogen auf die Benutzung von INSERT ON DUPLICATE KEY UPDATE dem Verhalten von PRIMARY KEY, womit ich, nach Tests mit der nach deinem Vorbild geänderten Struktur, keine Probleme sehe.

Das hatte ich in der BOOKMARK-Tabelle auch so vorgesehen, bis ich die Signatur der move_item-Funktion gesehen habe, die einen ID erfordert.

Der Satz bezieht sich in Sachen move_item ausschließlich auf die Bookmark-Funktion? Sortieren brauchen wir beim Gelesen-Status ja nichts.

ENGINE/COLLATE

Diese Angaben übernehme ich von den Tabellendefinitionen der bereits vorhanden Tabellen.

Diese Tabelle wird in einem von angemeldeten Benutzern stark frequentierten Forum eine der am häufigsten geänderten Tabellen sein. Jeder Aufruf eines Beitrags durch einen angemeldeten Benutzer erzeugt oder ändert einen Datensatz in dieser Tabelle.

An dieser Stelle ist es sinnvoll, von den Fähigkeiten der InnoDB-Engine zu profitieren. Dazu gehören: Row Lock statt Table Lock bei MyISAM und Speicherung der Daten in der Reihenfolge der Primärschlüssel. Die gebotene Transaktionssicherheit werden wir bei diesem Feature hingegen nicht brauchen. Die InnoDB-Engine ist zwar, nachdem, was ich gelesen habe, über alles statistisch etwas langsamer, in diesem Einsatzszenario sollten aber der Vorteil, für einen Schreibvorgang nicht die ganze Tabelle, sondern nur die betroffene Zeile zu sperren, überwiegen.

Zusammengefasst: Die Schreibvorgange erfolgen, jeder für sich, zwar etwas langsamer, insgesamt (wenn im Forum viel los ist) aber schneller, weil mehrere Schreibvorgänge in verschiedenen Zeilen der Tabelle gleichzeitig stattfinden können.

In Sachen Collation bin ich mir nicht sicher, ob die Angabe beim erstellen der Tabelle von der Datenbankengine nicht einfach wegoptimiert wird. An der Stelle wäre das eine unnötige Angabe, die wir dann weglassen könnten. Ich teste das nochmal auf meinem Webspace.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo,

Der Satz bezieht sich in Sachen move_item ausschließlich auf die Bookmark-Funktion?

Ja.

Zum Rest: Ändere es doch einfach wieder. ;-)

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo

Zum Rest: Ändere es doch einfach wieder.

<rumnöl>Mimimi. Mach ich auch!</rumnöl> ;-)

Kommt dann mit meinem Cleanup-Branch, in dem ich die bisherigen Abfragen bereinige, zum Schluss dran. Die einzelnen Teilaufgaben, die vorher anstehen, sind von den fraglichen Strukturänderungen unabhängig.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo Milo

Das heißt, diese Information kann – z.B. mit einem Subquery, der je nach Status 0 oder 1 zurückgibt oder über einen Join – direkt an das Posting gebunden werden.

Genau. Über ein JOIN würde ich es lösen, da das vermutlich schnelle ist, als die doppelte Abfrage.

Ich habe mir die Abfrage aus der thread.inc.php genommen – die entsprechenden Abfragen in entry.inc.php, rss.inc.php, etc. sollten ja analog aussehen – und habe etwas herumexperimentiert. Wenn ich auf Subqueries setze, kann ich Statuswerte erzeugen (ja = 1, nein = 0), muss dafür aber einige Vorbereitungen treffen. Die Performancefalle wegen der Ausführung des Subqueries in jeder Ergebniszeile bei größeren Threads lasse ich mal gleich außen vor. Mit einem LEFT JOIN hingegen muss ich nur die Benutzer-ID bei Bedarf auf 0 setzen und den kleinen Umweg über Wert oder NULL gehen.

Ich würde auch gern Aliase für die Tabellennamen einbauen, um die Anzahl der Stellen, an denen die Namen mit PHP-Code eingefügt werden, zu verringern. Hältst du das für sinnvoll?

SELECT
 …,
 edit_key,
 rst.user_id AS req_user
FROM mlf2_entries AS ft
 LEFT JOIN mlf2_entries_cache AS ct
  ON ct.cache_id = ft.id
 LEFT JOIN mlf2_userdata AS ut
  ON ut.user_id = ft.user_id
 LEFT JOIN mlf2_userdata_cache AS uct
  ON uct.cache_id = ut.user_id
 LEFT JOIN mlf2_read_entries AS rst
  ON rst.posting_id = ft.id AND rst.user_id = ". intval($user_id) ."
 WHERE tid = ". intval($thread_id) ." ORDER BY ft.TIME ASC";

So werde ich das (bei Widerspruch ausnehmlich der Aliase) einbauen und dann bleibt noch die Aufgabe, das setzen der Klasse "read" und das Verhalten der Refresh-Funktion (mit der alles begonnen hat) anzupassen.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo,

Genau. Über ein JOIN würde ich es lösen, da das vermutlich schnelle ist, als die doppelte Abfrage.

Wenn ich auf Subqueries setze, kann ich Statuswerte erzeugen (ja = 1, nein = 0), muss dafür aber einige Vorbereitungen treffen.

Wenn ich mir das jetzt so ansehe, bin ich mir diesbezüglich gar nicht mehr so sicher. Es könnte also auch ein:

...
 edit_key,
IF ((SELECT TRUE FROM mlf2_read_entries WHERE mlf2_read_entries.posting_id = ft.id AND mlf2_read_entries.user_id = 1) = TRUE, TRUE, FALSE) AS `user_read`
 
FROM mlf2_entries AS ft
 LEFT JOIN mlf2_entries_cache AS ct
...

optimaler sein. In meinem Testforum mit vier Einträgen lässt es sich aber nicht genau verifizieren, sodass ich Dir keine Empfehlung geben kann. Welche weiteren Vorbereitungen noch nötig wären, weiß ich nicht. Auf die schnelle sollte die zusätzliche Zeile doch reichen, oder?

Ich würde auch gern Aliase für die Tabellennamen einbauen, um die Anzahl der Stellen, an denen die Namen mit PHP-Code eingefügt werden, zu verringern. Hältst du das für sinnvoll?

Ich _persönlich_ würde drauf verzichten, da es zwar kürzer aber gleichzeitig auch schwerer zu lesen ist. Im Moment ist sofort ersichtlich, aus welcher Tabelle der Wert kommt, dies würde nachher verloren gehen. Grundsätzlich ist es mir aver egal, da wir diesen SQL ja vermutlich nicht pausenlos anfassen werden. ;-)

das setzen der Klasse "read"

Durch die Zusätzliche Abfrage des read-Status wird ein weiteres Feld erzeugt, welches im Idealfall boolesch ist. Dieses steht dann automatisch im Template zur Verfügung. Bei meinem Vorschlag wäre dies also das Feld user_read. Das sollte daher einfach sein, würde ich meinen.

und das Verhalten der Refresh-Funktion (mit der alles begonnen hat) anzupassen.

Wobei ich hier gar nicht mehr weiß, für was Ihr Euch entschieden habt. ;-)

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo

Wenn ich mir das jetzt so ansehe, bin ich mir diesbezüglich gar nicht mehr so sicher. Es könnte also auch ein … [SUBSELECT] … optimaler sein. In meinem Testforum mit vier Einträgen lässt es sich aber nicht genau verifizieren, sodass ich Dir keine Empfehlung geben kann.

Mit meinem Forum, in dem ich ein paar mehr Testeinträge zur Templateentwicklung drin habe, werde ich auch keine aussagekräftigen Benchmarks erstellen können. Da müssen wir wohl auf Rückmeldungen warten. Optimierungen für nur eventuell vorhandene Performanzbremsen müssen wir IMHO nicht anpacken.

Grundsätzlich:

Auf mehreren Seiten habe ich die Aussage gefunden, dass speziell bei MySQL JOINs zu bevorzugen seien, eben weil der JOIN einmal beim einsammeln der Datensätze ausgeführt wird, wohingegen ein Subselect für jede Ergebniszeile erfolgt. Die Fundstellen sind allerdings auch alle schon einige Jahre alt gewesen.

Ob MySQL in der Hinsicht heutzutage besser optimiert oder auch nicht, kann ich schlicht nicht beurteilen. Zumal ja nicht jede MLF-Installation auf Servern mit (einigermaßen) aktueller Softwarebasis erfolgt. Der JOIN funktioniert jedenfalls, auch wenn er kein boolesches Ergebnis ausgibt (Zahl (INT) oder NULL statt TRUE oder FALSE).

Ich würde auch gern Aliase für die Tabellennamen einbauen, um die Anzahl der Stellen, an denen die Namen mit PHP-Code eingefügt werden, zu verringern. Hältst du das für sinnvoll?

Ich _persönlich_ würde drauf verzichten, da es zwar kürzer aber gleichzeitig auch schwerer zu lesen ist. Im Moment ist sofort ersichtlich, aus welcher Tabelle der Wert kommt, dies würde nachher verloren gehen. Grundsätzlich ist es mir aver egal, da wir diesen SQL ja vermutlich nicht pausenlos anfassen werden.

Hmm, bei leserlich notierten Queries würde ich dir (fast) uneingeschränkt recht geben. Die gegenwärtige Notatation in langen Zeilen mit PHP-Einsprengseln (eben zur Angabe der Tabellen oder Formatanweisungen) finde ich persönlich eben nicht leserlich. Aber das ist Geschmackssache.

Ich habe in den bisher editierten Dateien nur dort Aliase angegeben, wo sie für die neu eingebundene Tabelle notwendig waren. Es betrifft also die neue Tabelle und die Tabelle mlf2_forum_table mit den Einträgen (wegen des Vergleichs). Für die Forumstabelle habe ich das in den geänderten Queries aber auch konsequent durchgezogen. Überall anders habe ich es gelassen, wie es war.

und das Verhalten der Refresh-Funktion (mit der alles begonnen hat) anzupassen.

Wobei ich hier gar nicht mehr weiß, für was Ihr Euch entschieden habt.

"Gelesen" ist und bleibt gelesen, bis ein evtl. eingeschalteter Automatismus (den du letzter Tage committet hast) zuschlägt und die Markierung aufhebt. Wird der Refresh-Link benutzt, werden neue Einträge geladen und die Neu-Markierung (der Pfeil bzw. der rote Rand am Thread-Icon) bei bereits gelesenen Einträgen gelöscht.

Das hat, wenn es denn richtig[tm] funktioniert, den weiteren Vorteil, dass ein beim letzten Besuch nicht gelesener Beitrag auch beim nächsten Besuch als ungelesen/neu angezeigt wird. Das nervt mich nämlich in so manchem Forum. Ein Beitrag, den ich jetzt nicht lesen will, finde ich beim nächsten Besuch nur mit Handständen wieder.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hello

Show views of all entries in a thread instead only of the opening entry in the table view (thread in a hidden category and thatswhy not linked).
Is this fixed?

Yes, it's fixed.

Status 404 for images in a custom theme. It's probably an error of the theme creator, but maybe not.
Should be investigated.

Seems to be a problem in the custom theme, not in the forum script.

There seems to be a RSS-issue, where new entries doesn't show up instantaneously in some clients. Maybe client-issues, maybe a problem with time format?
Should be investigated.

The entries shown up in the RSS-feed instantaneously. So it couldn't be a problem with the generation of the feed but a problem in the reader software.

A second issue with RSS, that came up a few minutes ago. The feed is updated every time a new entry is posted. There is no update in case of a deletion of an entry or a thread. An entry will furthermore reside in the feed even if it is removed from the forum.
Should be investigated.

I don't find the source of the problem. Deferred until the cause is describable.

Images in the feed was reported to be broken (wrong path given).
Is this fixed? (my feed-reader only provides the entries headers and some metadata)

Is it wise to include the images into the feed? They can be originated from any sources, the forum (with it's upload function) but also form any URL from the web. Additionally the transmission of the images to a RSS-reader causes a bunch of additional traffic.

I for myself use a RSS-reader on my phone and another one on a PC. On the phone I don't like the additional traffic because of the limited allowed monthly traffic in my contract. So I would prefer to get the feed without the images. If I want to see them, I can visit the forum at a place or with a device, where I know, that the traffic is not a problem.

A problem with the Ajax-preview-bubble was reported.
I for myself can't confirm the behaviour. On the other hand images should IMHO shrinked to a bit less of 100% of the width and/or height.

Solved.

A feature request was to have infinite scrolling in the overview pages.
I personally like the idea, am not able to realise it and have no clue about the effort.

Deferred.

A further request is to have a report-spam/abuse-link or button.
Is this of any importance? I would support it in principle but don't want to exceed the task list.

Any thoughts?

Someone wanted to have tab order for buttons, mainly in the posting form.
This is (not only!) important for disabled persons. But at that point I have further questions about the UI and especially the font size.

Next task after bug fixing.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hello

After a few weeks of silence (christmas, turn of the year, real life and such things) I want to release the first public development snapshot as I stated in the Github-issue #152. Before I'll do so, I wan't to repeat the leftover relevant questions.

Images in the feed was reported to be broken (wrong path given).
Is this fixed? (my feed-reader only provides the entries headers and some metadata)

Is it wise to include the images into the feed? They can be originated from any sources, the forum (with it's upload function) but also form any URL from the web. Additionally the transmission of the images to a RSS-reader causes a bunch of additional traffic.

I for myself use a RSS-reader on my phone and another one on a PC. On the phone I don't like the additional traffic because of the limited allowed monthly traffic in my contract. So I would prefer to get the feed without the images. If I want to see them, I can visit the forum at a place or with a device, where I know, that the traffic is not a problem.

and

A further request is to have a report-spam/abuse-link or button.
Is this of any importance? I would support it in principle but don't want to exceed the task list.

Any thoughts?

Is a quick fix possible here or should it be deferred?

Should an abuse or a spam report trigger an email addressed to the team members or should it be stored in a new message infrastructure in the admin area?

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi, has the report-spam/abuse-link or button been added in 2.3.99.2 or will it be in 2.4 at all?

Also 2 other things (I'm on 2.3.7)

1. Once you pick a gender in the profile you cannot then deselect a gender for example If I decide I as a user do not want to show my gender anymore.

2. I have the forum setup to allow users to edit only for 30 minutes, if user selects 'notification of reply' there is no way of unsubscribing from this notification after 30 minutes. I think notification emails should have a unsubscribe link.

Hi, has the report-spam/abuse-link or button been added in 2.3.99.2 or will it be in 2.4 at all?

Because I got no answer to my questions …

A further request is to have a report-spam/abuse-link or button.

Is this of any importance? I would support it in principle but don't want to exceed the task list.

Any thoughts?

Is a quick fix possible here or should it be deferred?

Should an abuse or a spam report trigger an email addressed to the team members or should it be stored in a new message infrastructure in the admin area?

… the report-button will definitively not included into the version 2.4(.0). But I for myself am interested to include a reporting function. It's very likely, that the function comes with one of the minor updates of the 2.4-branch. I sat up an issue (#156) with the provisional goal to include it in 2.4.1. But it's not unlikely, that it will, because of the new table, be deferred to the version 2.5.

1. Once you pick a gender in the profile you cannot then deselect a gender for example If I decide I as a user do not want to show my gender anymore.

Yes, that's a bad behaviour. It's caused by the lack of a not-specified-state in the gender-group of form fields. I'll see, if I can include it without any trouble. I sorted the issue (#157) into the milestone 2.4.1 but it's very likely, that it will be accomplished until the 2.4 release.

2. I have the forum setup to allow users to edit only for 30 minutes, if user selects 'notification of reply' there is no way of unsubscribing from this notification after 30 minutes. I think notification emails should have a unsubscribe link.

With the new introduced subscription feature the notification-feature in it's old form should IMHO be removed. When an author get's an auto subscription for his entries, he would only need to unsubscribe from the entry or thread. No need for enhancements for a from now on unnecessary feature. But that's IMHO not a very urgent task.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hello

1. Once you pick a gender in the profile you cannot then deselect a gender for example If I decide I as a user do not want to show my gender anymore.

This was done with PR #163 and will be part of version 2.4 (it's now in the beta 2.3.99.3).

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi, I have two more suggestions regarding search for future updates that maybe you could think about.

1. I've found it would be nice to have on the search page radio buttons for All and Original posting so you can filter search results and view just original postings not replies

2. It would also be nice if when you're in a category for example on this site 'Bugs' and you do a search it automatically defaults to search the 'Bugs' category only!

at the moment if I'm viewing the 'Bugs' category and do a search it gives me all categories and I need to then click 'Bugs' in the drop down menu and click search.

Obviously if you're in All Categories category and do a search it searches site wide.

Not sure how hard this would be to implement or how you feel about it but I think it would be more intuitive.

Hello

1. I've found it would be nice to have on the search page radio buttons for All and Original posting so you can filter search results and view just original postings not replies

I for myself think, that this would not be very useful. I search for keywords and in the moment of search I don't know, wich entries will match the keywords. I wouldn't want such a constriction of the results to only thread openers or only replies.

Maybe it could be a setting in an enhanced search.

2. It would also be nice if when you're in a category for example on this site 'Bugs' and you do a search it automatically defaults to search the 'Bugs' category only!

To stay in your example; What, if a poster reported a bug but selected another category for the entry? You'll not find this entry without changing the category (and: you have to know this mechanism!).

I think, it's reasonable to search for result in the selected category. But it is not reasonable to exclude valid results from the search because of their differing category. In my humble opinion it would be enough to order the results from the matching category to the top of the result list.

at the moment if I'm viewing the 'Bugs' category and do a search it gives me all categories and I need to then click 'Bugs' in the drop down menu and click search.

Yeah, that's a "feature" of the enhanced search and an ordered list of search results (as mentioned above) would make a change superfluous.

Further ideas‽

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi Auge,

Further ideas‽

As you know, I love the extended search feature of the Netz-Treff („aufgebohrte” v1.x of mlf). In my forum there are just ~16,000+ posts but sometimes it takes me ages to find sumfink since I can’t narrow the search (f.i. if I remember who posted and/or in which year).

--
Cheers,
Alfie (Helmut Schütz)
BEBA-Forum (v1.8β)

Hi Alfie,

it takes me ages to find sumfink since I can’t narrow the search

The new bookmark-option will improve this behaviour. ;-)

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hello Alfie and Milo

it takes me ages to find sumfink since I can’t narrow the search

The new bookmark-option will improve this behaviour.

Not in Alfie's forum. I developed a subscription function for mlf1 a few years ago and it should be part of his installation. In the german language file it's named "Abonnements" like in mlf2. But it's for being informed via email in the case of a new answer to an entry or a new entry in a thread (what was impossible previously), not to store interesting entries in an users own list.

At that point it might be reasonable to rethink the tagging of the entries. Who is allowed to tag an entry at the moment? Team members, registered users, everyone (when it's allowed to everyone to post entries)? Tags could be a much more powerful feature, especially for searching an entry.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Further ideas‽

Tschö, Auge

:lookaround: Multiple Image upload :clap: My users post a lot of images and it would be such a time saver. Could tell users to use an image host but if that site goes away it ruins your site.

Hello (especially Milo)

The code for displaying and not-displaing of HTML-elements changed from altering the (inline)-styles to altering class names. There is a small problem (for me). I want to alter other elements and to set the CSS-rules with inheritance.

Let's describe an example. The entries in nested view are foldable with a klick into the title box. In the past a click altered the inline styles of the elements, that should be hidden. In the present the click alters class names in the elements, that should be hidden. With the exception of the difference between inline styles and class names no difference in the behaviour.

The following is the new in the alpha-code introduced behaviour.

visible entry:

<div class="thread-posting read" id="p1">
 <div class="header">
  <img id="avatar-1" class="avatar" src="…" alt="Avatar" width="80" height="80">
  <h1 id="headline-1" class="js-cursor-pointer" title="Eintrag ein-/ausklappen">…</h1>
  <p class="author">…</p>
 </div>
 <div class="wrapper" id="posting-1">
  <div class="body">…</div>
  <div class="posting-footer">
   <div class="reply">…</div>
   <div class="info">…</div>
  </div>
 </div>
</div>

invisible entry (please take notice of the class js-display-none for the avatar and the div.wrapper):

<div class="thread-posting read" id="p1">
 <div class="header">
  <img id="avatar-1" class="avatar js-display-none" src="…" alt="Avatar" width="80" height="80">
  <h1 id="headline-1" class="js-cursor-pointer" title="Eintrag ein-/ausklappen">…</h1>
  <p class="author">…</p>
 </div>
 <div class="wrapper js-display-none" id="posting-1">
  <div class="body">…</div>
  <div class="posting-footer">
   <div class="reply">…</div>
   <div class="info">…</div>
  </div>
 </div>
</div>

I want to change it to the following. What I want, is the assignment of the class to the parent element.

<div class="thread-posting read js-display-none" id="p1">
 <div class="header">
  <img id="avatar-1" class="avatar" src="…" alt="Avatar" width="80" height="80">
  <h1 id="headline-1" class="js-cursor-pointer" title="Eintrag ein-/ausklappen">…</h1>
  <p class="author">…</p>
 </div>
 <div class="wrapper" id="posting-1">
  <div class="body">…</div>
  <div class="posting-footer">
   <div class="reply">…</div>
   <div class="info">…</div>
  </div>
 </div>
</div>

That way it is possible to set for theme A:

div.thread-posting.js-display-none .avatar {
  width: 1em;
  height: 1em;
}
div.thread-posting.js-display-none .body {
  display: none;
}

… and for the theme B:

div.thread-posting.js-display-none .avatar,
div.thread-posting.js-display-none .wrapper {
  display: none;
}

I would like to have the same behaviour for #sidebar and #bottombar. Is the idea supportable?

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi,

I want to change it to the following. What I want, is the assignment of the class to the parent element.

Add a new class in the template, if you can not select the parent itself. This seems to be the easiest way.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hello

I want to change it to the following. What I want, is the assignment of the class to the parent element.

Add a new class in the template, if you can not select the parent itself. This seems to be the easiest way.

Sorry, but I don't understand your attempt. The class should be included and removed with a click or a tap. Therefor this must be handled with JavaScript. If I set the class hardcoded into the template, one can't toggle the visibility of entries and sidebar-blocks.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi,

Therefor this must be handled with JavaScript.

Maybe, but not by the class js-display-none to avoid interactions with other code parts.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hello

Therefor this must be handled with JavaScript.

Maybe, but not by the class js-display-none to avoid interactions with other code parts.

Yes, that's correct. My first tests with an unchanged class name but with an altered CSS-rule, that selected child elements instead the elements itself, caused a viewport filling overlay with the div.ajax-preview, div.image-canvas and/or div.bbcode-options. :-)

We need (a) different class name(s) for the side- and bottombar and the postings in the nested view.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi,

We need (a) different class name(s) for the side- and bottombar and the postings in the nested view.

Okay, but let us defer this issue - behind the release 2.4.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hello

We need (a) different class name(s) for the side- and bottombar and the postings in the nested view.

Okay, but let us defer this issue - behind the release 2.4.

It's a pity, because I want to go further with my theme and release a first serious pre-release after and for the version 2.4. Therfor I planned with the new classes.

It will not look nice as planned, but it will also do it's job without the classes.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi,

no free time anymore...

It will not look nice as planned, but it will also do it's job without the classes.

Take a look at: https://github.com/ilosuna/mylittleforum/tree/JavaScript or should I add a PR?

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hello

no free time anymore...

That's ok.

Take a look at: https://github.com/ilosuna/mylittleforum/tree/JavaScript or should I add a PR?

I will test the code in my own forum and give a report afterwards.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hello Milo

I tested your changes. I added a small change, a different class name and played a bit with it. Nice, very nice! Because of the additional changes, I will add the code myself, if it's o.k. for you.

Thank you.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi Auge,

I tested your changes. I added a small change, a different class name and played a bit with it. Nice, very nice!

Fine!

Because of the additional changes, I will add the code myself, if it's o.k. for you.

Of course. ;-) I removed my branch to avoid conflicts with your add. changes.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hello

no free time anymore...

Take a look at: https://github.com/ilosuna/mylittleforum/tree/JavaScript

I did it myself with your work as a rock solid base. Thank you. You can remove the branch "JavaScript" at any time. Or you store it for further experiments. :-)

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

RSS Feed of thread