Avatar

mögliche Wege, MLF1 weiter zu betreiben (General)

by Auge ⌂, Sunday, March 31, 2019, 18:04 (1824 days ago)

Hallo Alfie

Ich möchte dich bitten, im Nachbarthread zum Thema "MLF1 unter PHP7 oder besser Update auf MLF2.x?" etwas zum ersten Teil des Themas (MLF1 mit PHP7.x) zu schreiben. Ich gehe davon aus, dass du dein Forum nicht in einer Asbach-Uralt-Umgebung laufen lässt und vielleicht die eine oder andere diesbezügliche Anpassung vorgenommen hast.

Wie ich in der dortigen Antwort schon schrieb, habe ich aktuell weder Zeit, Geduld noch Muße die nötigen Änderungen vorzunehmen, auch wenn der Großteil dieser Änderungen im alten dev-Branch schlummert. Wenn ich denn Hilfe in Form von Bugmeldungen und Pull Requests bekäme, wäre das wohl etwas anderes, aber als Einzelkämpfer geht es definitiv nicht.

Hast du in der Hinsicht selbst schon etwas getan oder versuchst auch du, solange wie möglich auf einer PHP5-Version zu verharren?

Tschö, Auge

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

Avatar

mögliche Wege, MLF1 weiter zu betreiben

by Alfie ⌂, Vienna, Austria, Sunday, March 31, 2019, 20:47 (1824 days ago) @ Auge

Hallo Auge,

[…] Ich gehe davon aus, dass du dein Forum nicht in einer Asbach-Uralt-Umgebung laufen lässt […]

Doch.

Hast du in der Hinsicht selbst schon etwas getan oder versuchst auch du, solange wie möglich auf einer PHP5-Version zu verharren?


Ich „stehe” lt. meiner Einstellunge im Webhost-Admin auf PHP5.6 – obwohl mir phpinfo() beharrlich 5.3.3-7 anzeigt. Wie auch immer. Höhere stellt mein Provider nicht zur Verfügung (ausser auf dedicated Servern; ist mir für ein Hobby einfach zu teuer). Risken sind mir bewusst. Sollte etwas Übles passieren, zieh’ ich dem Forum den Stecker.

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

Avatar

mögliche Wege, MLF1 weiter zu betreiben

by Auge ⌂, Monday, April 01, 2019, 20:18 (1823 days ago) @ Alfie

Hallo

[…] Ich gehe davon aus, dass du dein Forum nicht in einer Asbach-Uralt-Umgebung laufen lässt […]


Doch.

Damit habe ich nun echt nicht gerechnet.

Hast du in der Hinsicht selbst schon etwas getan oder versuchst auch du, solange wie möglich auf einer PHP5-Version zu verharren?


Ich „stehe” lt. meiner Einstellunge im Webhost-Admin auf PHP5.6 – obwohl mir phpinfo() beharrlich 5.3.3-7 anzeigt. Wie auch immer. Höhere stellt mein Provider nicht zur Verfügung (ausser auf dedicated Servern; ist mir für ein Hobby einfach zu teuer).

Ich kann die Hosting-Situation in Österreich nicht einschätzen. Bei den deutschen Hostern, mit denen ich so zu tun habe, ist PHP 7.2 oder höher normal, auch ohne einen Dedicated Server zu mieten, sondern ganz normal mit Webspace für 3 bis 5 €/Monat. Bei ein paar der Hoster könnte ich auch PHP 5.6 oder sogar hinunter bis PHP 5.4 auswählen. Aber warum sollte ich das wollen?

Risken sind mir bewusst. Sollte etwas Übles passieren, zieh’ ich dem Forum den Stecker.

Ich hoffe nicht. Abgesehen vom Beispiel deines Forums, dass ich immer wieder nennen kann, wäre es schade, ein nach meiner Einschätzung so gut aus allen Ecken dieses Planeten frequentiertes Fachforum zu schließen. Diese Reputation hast du ja nun weit über 10 Jahre lang aufgebaut. Es wäre wirklich schade, das einfach wegzuwerfen. :-(

Tschö, Auge

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

Avatar

mögliche Wege, MLF1 weiter zu betreiben

by Alfie ⌂, Vienna, Austria, Monday, April 01, 2019, 22:24 (1822 days ago) @ Auge
edited by Alfie, Tuesday, April 02, 2019, 08:31

Hallo Auge,

Doch.


Damit habe ich nun echt nicht gerechnet.

Seh’n se?

Ich kann die Hosting-Situation in Österreich nicht einschätzen.

Ich auch nicht. Nach dem 2× gehackten Server hatte ich die Schnauze voll. Den Umzug zum Silver Server hast du ja hautnah miterlebt. Wie die Jungfrau zum Kind kam ich anschließend – ungefragt – über Tele2 zu 3. Ich habe gestern dem Support gemehlt und angefragt wie’s ihnen denn so geht…

Risken sind mir bewusst. Sollte etwas Übles passieren, zieh’ ich dem Forum den Stecker.


Ich hoffe nicht.

Ich schon gar nicht. ;-)
War ein langer Weg. UTF-8, HTML5, CSS-Sprites, Bildchen/JS/CSS von Cookie-freier Domain, TLS,…
Nö, ein responsive design werd’ ich mir nie antun. Da können die Google Webmaster Tools noch so sehr meckern. Meine User hocken hinter Riesenbildschirmen.

Abgesehen vom Beispiel deines Forums, dass ich immer wieder nennen kann, wäre es schade, ein nach meiner Einschätzung so gut aus allen Ecken dieses Planeten frequentiertes Fachforum zu schließen. Diese Reputation hast du ja nun weit über 10 Jahre lang aufgebaut. Es wäre wirklich schade, das einfach wegzuwerfen. :-(

Yessir!
Inwischen habe ich vorsorglich begonnen, die mysql_* Funktionen durch mysqli_* zu ersetzen. Ein Fass ohne Boden. Bekäme ich nur das „Genie” in die Finger, das die Syntax umgedreht hat (zB mysql_query($query, resource) → mysqli_query(resource, $query))! Ätzend.*

--
* grepl in R bemüht: mysql_ kommt in meiner Code-Basis 408 mal vor. :-( Da sind die 26 schon durch mysqli_ ersetzten nur peanuts.

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

Avatar

mögliche Wege, MLF1 weiter zu betreiben

by Auge ⌂, Tuesday, April 02, 2019, 09:44 (1822 days ago) @ Alfie

Hallo Alfie

… Wie die Jungfrau zum Kind kam ich anschließend – ungefragt – über Tele2 zu 3. Ich habe gestern dem Support gemehlt und angefragt wie’s ihnen denn so geht…

:-) PHP 7 heutzutage nicht anzubieten, ist, gelinde gesagt, schoflig. PHP 5.6 hat gerade eben (Januar 2019) sein letztes geplantes Sicherheitsfix-Release (5.6.40) bekommen. Alle älteren Versionen sind veraltet und ungepflegt.

War ein langer Weg. UTF-8, HTML5, CSS-Sprites, Bildchen/JS/CSS von Cookie-freier Domain, TLS, …
Nö, ein responsive design werd’ ich mir nie antun. Da können die Google Webmaster Tools noch so sehr meckern. Meine User hocken hinter Riesenbildschirmen.

Wenn du ein responsives Desing benutzt, tust du das für deine Benutzer und nicht für irgendwelche Webmastertools. Zumal gerade Google an dieser Stelle kein neutraler Bewerter ist, die wollen den Seitenbetreibern für eine eventuell bessere Position in den Suchergebnislisten ihre eigenen Techniken unterjubeln, mit denen sie den Traffic kontrollieren und damit die Daten der Besucher mitlesen können.

Deine Wahrnehmung, dass ja alle™ Benutzer „hinter Riesenbildschirmen“ hocken, könnte im Übrigen auch Ursache und Wirkung vertauschen. ;-) Wenn die Seite auf einem Smartphone unbenutzbar ist, wird sich das auch niemand antun, auch wenn er es eigentlich wollte.

Inwischen habe ich vorsorglich begonnen, die mysql_* Funktionen durch mysqli_* zu ersetzen. Ein Fass ohne Boden. Bekäme ich nur das „Genie” in die Finger, das die Syntax umgedreht hat (zB mysql_query($query, resource) → mysqli_query(resource, $query))! Ätzend.*

Ich habe vorgestern angefangen, alle Dateien der Version 1.7.7 durchzuarbeiten (was dir wegen des anderen Ausgangspunkts nicht direkt nutzt). Ich bin bis auf die admin.php und die lang_add-Dateien durchgekommen und habe dabei wieder, wie schon einmal vor neun Jahren, vor dem alten, uneinheitlichen Stand der Queries gesessen. Integers und Variablen für solche in Anführungszeichen, Variablen für Integers ohne kontextgerechte Behandlung, Zeichenketten, ebenfalls ohne kontextgerechte Behandlung. Es ist zum Zehennägelhochrollen!

Man sieht dem Code seine mehrjährige Entwicklung sowie die anfängliche Unwissenheit und das Dazulernen der beteiligten Entwickler an. :-)

--
* grepl in R bemüht: mysql_ kommt in meiner Code-Basis 698 mal vor. :-( Da sind die 54 schon durch mysqli_ ersetzten nur peanuts.

Auch die originale Codebasis enthält eine ähnliche Anzahl von Fundstellen. Die admin.php, die zu bearbeiten ich gestern Abend begann, enthält davon den größten Haufen. :-|

Tschö, Auge

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

Avatar

mögliche Wege, MLF1 weiter zu betreiben

by Alfie ⌂, Vienna, Austria, Tuesday, April 02, 2019, 18:48 (1822 days ago) @ Auge

Hallo Auge,

:-) PHP 7 heutzutage nicht anzubieten, ist, gelinde gesagt, schoflig.

Du sagst es. Mein Support schweigt.

Wenn du ein responsives Desing benutzt, tust du das für deine Benutzer und nicht für irgendwelche Webmastertools.

Schon klar.

Deine Wahrnehmung, dass ja alle™ Benutzer „hinter Riesenbildschirmen“ hocken, könnte im Übrigen auch Ursache und Wirkung vertauschen. ;-) Wenn die Seite auf einem Smartphone unbenutzbar ist, wird sich das auch niemand antun, auch wenn er es eigentlich wollte.

Jein. Also im Job, auf der Uni etc. hat man(n) mindestens einen Laptop. Zuhause ebenso – vielleicht auch ein Tablett. Die 3% Zugriffe von „mobile devices” stammen vermutlich von Google im Nörgelmodus oder mir selbst mit meinem uralt-Kindle Fire. Bis zu der Bildschirmgröße noch OK. Handy? Ach nee.

Ich habe vorgestern angefangen, alle Dateien der Version 1.7.7 durchzuarbeiten […]. Ich bin bis auf die admin.php

Ist ja auch monströs. Bei mir 2920 Zeilen.

… und habe dabei wieder, wie schon einmal vor neun Jahren, vor dem alten, uneinheitlichen Stand der Queries gesessen. Integers und Variablen für solche in Anführungszeichen, Variablen für Integers ohne kontextgerechte Behandlung, Zeichenketten, ebenfalls ohne kontextgerechte Behandlung. Es ist zum Zehennägelhochrollen!

Korrekt. Ich bin „durch” was die Forumsskripte betrifft (meine Zusätze morgen, vielleicht).

Man sieht dem Code seine mehrjährige Entwicklung sowie die anfängliche Unwissenheit und das Dazulernen der beteiligten Entwickler an. :-)


Ach ja. :-)

Auch die originale Codebasis enthält eine ähnliche Anzahl von Fundstellen. Die admin.php, die zu bearbeiten ich gestern Abend begann, enthält davon den größten Haufen. :-|

Am Ende hatte ich 343 Ersetzungen. Ca. ⅔ einfaches replace, aber die Vertauschung in mysqli_query($source, $string) war echt mühsam. Ich kann nachvollziehen, dass mit parallel laufenden APIs die Funktionsnamen geändert werden müssen. Die neue Reihenfolge im query ist syntaktisch auch nachvollziehbar: Wo soll ich suchen und was? Wieauchimmer, Manöverbericht:
Die neuen Skripte hochgeladen und zunächst sieht alles gut aus, ich kann mich sogar als neuer User registrieren. Toll. Einloggen? Nicht um die Bohne. Dabei hat login.php bei mir lumpige 450 Zeilen. Zum Mäusemelken. Temporär wieder zurückgerudert. Wär’ doch gelacht!

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

Avatar

mögliche Wege, MLF1 weiter zu betreiben

by Auge ⌂, Tuesday, April 02, 2019, 19:10 (1822 days ago) @ Alfie

Hallo Alfie

:-) PHP 7 heutzutage nicht anzubieten, ist, gelinde gesagt, schoflig.


Du sagst es. Mein Support schweigt.

:-(

Also im Job, auf der Uni etc. hat man(n) mindestens einen Laptop. Zuhause ebenso – vielleicht auch ein Tablett. Die 3% Zugriffe von „mobile devices” stammen vermutlich von Google im Nörgelmodus oder mir selbst mit meinem uralt-Kindle Fire. Bis zu der Bildschirmgröße noch OK. Handy? Ach nee.

Wie du in meinem Forümchen mit einem Smartphone, das du eigenen Bekundungen nach nicht hast, sehen könntest, geht das grundsätzlich schon (ersatzweise geht auch das Testen von Bildschirmgrößen in den Entwicklerwerkzeugen des Desktop-Browsers). Es handelt sich immer um die selbe Codebasis, in jedem Browser.

Ich habe vorgestern angefangen, alle Dateien der Version 1.7.7 durchzuarbeiten […]. Ich bin bis auf die admin.php


Ist ja auch monströs. Bei mir 2920 Zeilen.

Ja, und ohne weitere Änderungen 200 Fundstellen von mysql_, die ich mittlerweile alle abgearbeitet habe (Task 1 von 3 erledigt).

Wieauchimmer, Manöverbericht:
Die neuen Skripte hochgeladen und zunächst sieht alles gut aus, ich kann mich sogar als neuer User registrieren. Toll. Einloggen? Nicht um die Bohne. Dabei hat login.php bei mir lumpige 450 Zeilen. Zum Mäusemelken. Temporär wieder zurückgerudert. Wär’ doch gelacht!

Könnte das an anderen Funktionen liegen? Wenn du beim Ersetzungsmarathon keine Fehler gemacht haben solltest, gibt es keinen Grund, warum du dich nicht einloggen können solltest.

Hast du mal bei der Fehlerausgabe nachgeholfen? Der folgende Block am Beginn der inc.php sollte reichen.

ini_set('display_errors', 1);
error_reporting(E_ALL);

Ob etwas drin steht, bleibt abzuwarten.

Tschö, Auge

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

Avatar

fast schon OT

by Alfie ⌂, Vienna, Austria, Wednesday, April 03, 2019, 13:24 (1821 days ago) @ Auge

Hallo Auge,

der Support hat gesprochen. Ich konnte nicht weg von 5.3, weil im Hintergrund wg. TLS / Proxy, wasauchimmer. Jetzt stehe ich glorreich bei 5.6.26 (release 15.9.2016, build 4.5.2017).

php7 (mehrere Versionen zur Auswahl) „wird es im Lauf des Jahres geben”. Aha.

Wie du in meinem Forümchen mit einem Smartphone, das du eigenen Bekundungen nach nicht hast, sehen könntest, geht das grundsätzlich schon (ersatzweise geht auch das Testen von Bildschirmgrößen in den Entwicklerwerkzeugen des Desktop-Browsers). Es handelt sich immer um die selbe Codebasis, in jedem Browser.

OK, OK. Vielleicht mach ich mir diese Baustelle auch noch auf.

Hast du mal bei der Fehlerausgabe nachgeholfen? Der folgende Block am Beginn der inc.php sollte reichen.

Ja und es gibt zwei Probleme. Beim dem „alten” Code scheint es Probleme mit nicht initialisierten Variablen der Zeitdifferenz zu geben (stammt aus funcs.processing.php):

function processUserTimeSplit($timeDiff) {
 
if (!empty($timeDiff)
and preg_match("/^(-|\+)(([0-1][0-9])|([2][0-3])):([0-5][0-9]):([0-5][0-9])$/", $timeDiff))
 {
 $utd[0] = substr($timeDiff, 0, 1);
 $utd[1] = substr($timeDiff, 1);
 }
else
 {
 $utd[0] = "+";
 $utd[1] = "00:00:00";
 }
return $utd;
} # End: processUserTimeSplit


Gleicher Fehler in alten wie neuen Funtionen. Also muss ich erst einmal die alte Baustelle lösen. Warum ich mich mit dem alten Code einloggen kann und mit dem neuen nicht, erschließt sich mir nicht.

Soll sein. Inzwischen XAMPP 7.3.3 installiert und meine Datenbank importiert. Derzeit kämpfe ich mit den connects. Etwa das da:

<?php
  $host = "host";
  $user = "user";
  $pw   = "FdhdGggswhgswh18#";
  $db   = "db";
  $conn_db = mysqli_connect($host, $user, $pw, $db);
  if (!$conn_db) {
    echo "<p>Connecting to database failed.</p>" . "\n";
    exit();
  } else {
    mysqli_set_charset($conn_db, "utf8");
    $txt = "<p>Database connection established.</p>" . "\n";
    $txt = $txt . "<pre>host: " . $host . "<br>" . "\n";
    $txt = $txt . "user: " . $user . "<br>" . "\n";
    $txt = $txt . "pw  : " . $pw . "<br>" . "\n";
    $txt = $txt . "db  : " . $db . "</pre>" . "\n";
    echo $txt;
  }
  $query = "SELECT time, zeit, subject, cattext, id, tid, name, ip
            FROM mlf_entrycats WHERE category != 15
            GROUP BY id ORDER BY zeit desc, id desc
            LIMIT 0, 20";
  $result = mysqli_query($conn_db, $query);
  if (!$result) {
    echo "<p>Reading from the database failed:<br>".mysqli_error($conn_db)."</p>"."\n";
    exit();
  }
?>


Spuckt mir das da aus:

Database connection established.

host: host
user: user
pw  : FdhdGggswhgswh18#
db  : db

Reading from the database failed:
The user specified as a definer ('db'@'%') does not exist

Scharf beobachtet! Das ist ja nicht der User sondern die Datenbank. Irre.

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

Avatar

fast schon OT

by Auge ⌂, Wednesday, April 03, 2019, 19:05 (1821 days ago) @ Alfie

Hallo Alfie

Inzwischen XAMPP 7.3.3 installiert und meine Datenbank importiert. Derzeit kämpfe ich mit den connects. Etwa das da:

<?php
$host = "host";
$user = "user";
$pw   = "FdhdGggswhgswh18#";
$db   = "db";
$conn_db = mysqli_connect($host, $user, $pw, $db);
if (!$conn_db) {
echo "<p>Connecting to database failed.</p>" . "\n";
exit();
} else {
mysqli_set_charset($conn_db, "utf8");
$txt = "<p>Database connection established.</p>" . "\n";
$txt = $txt . "<pre>host: " . $host . "<br>" . "\n";
$txt = $txt . "user: " . $user . "<br>" . "\n";
$txt = $txt . "pw  : " . $pw . "<br>" . "\n";
$txt = $txt . "db  : " . $db . "</pre>" . "\n";
echo $txt;
}
$query = "SELECT time, zeit, subject, cattext, id, tid, name, ip
FROM mlf_entrycats WHERE category != 15
GROUP BY id ORDER BY zeit desc, id desc
LIMIT 0, 20";
$result = mysqli_query($conn_db, $query);
if (!$result) {
echo "<p>Reading from the database failed:<br>".mysqli_error($conn_db)."</p>"."\n";
exit();
}
?>


Spuckt mir das da aus:

Database connection established.

Die Verbindung kommt also zustande.

Reading from the database failed:
The user specified as a definer ('db'@'%') does not exist

Scharf beobachtet! Das ist ja nicht der User sondern die Datenbank. Irre.

Mit der Fehlermeldung bin ich auf diesen Stack-Overflow-Thread gestoßen. Dort ist die Rede von der möglichen Fehlerursache Datenbankexport mit fehlenden Objekten.

Zitat von dort: "The user who originally created the SQL view or procedure has been deleted. If you recreate that user, it should address your error."

In einem anderen Beitrag heißt es: "This commonly occurs when exporting views/triggers/procedures from one database or server to another as the user that created that object no longer exists."

Das lässt mich vermuten, dass irgendwo in den Metadaten der Ersteller der Tabelle oder des Views mlf_entrycats (der Name taucht weder in der Version 1.7.6/1.7.7 noch in der von uns installierten Version 1.8 Beta auf) gespeichert wird, aber in deiner Testdatenbank nicht existiert.

Ich hoffe, dass das zielführend ist.

Tschö, Auge

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

Avatar

fast schon OT

by Alfie ⌂, Vienna, Austria, Wednesday, April 03, 2019, 22:13 (1820 days ago) @ Auge

Hallo Auge,

danke; ich habe genau das entdeckt aber ein paar Abend-Bierchen dazwischengeschoben. Mit diesem Code greife ich tatsächlich auf eine view zu. Die wurde zwar importiert, aber der Benutzer lies sich nicht ändern. Nach Neuanlegen klappte es.

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

Avatar

fast schon OT

by Auge ⌂, Wednesday, April 03, 2019, 19:13 (1821 days ago) @ Alfie

Hallo Alfie

Hast du mal bei der Fehlerausgabe nachgeholfen?


Ja und es gibt zwei Probleme. Beim dem „alten” Code scheint es Probleme mit nicht initialisierten Variablen der Zeitdifferenz zu geben (stammt aus funcs.processing.php):

function processUserTimeSplit($timeDiff) {
 
if (!empty($timeDiff)
and preg_match("/^(-|\+)(([0-1][0-9])|([2][0-3])):([0-5][0-9]):([0-5][0-9])$/", $timeDiff))
{
$utd[0] = substr($timeDiff, 0, 1);
$utd[1] = substr($timeDiff, 1);
}
else
{
$utd[0] = "+";
$utd[1] = "00:00:00";
}
return $utd;
} # End: processUserTimeSplit

Die Funktion hast du hinzugefügt? Im letzten Stand des dev-Branches, aus dem (vor diesem Stand) deine Version erstellt wurde, kommt die Funktion nicht vor.

Gleicher Fehler in alten wie neuen Funtionen. Also muss ich erst einmal die alte Baustelle lösen. Warum ich mich mit dem alten Code einloggen kann und mit dem neuen nicht, erschließt sich mir nicht.

Wie lautet denn die PHP-Fehlermeldung bezüglich der oben gezeigten Funktion?

Tschö, Auge

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

Avatar

fast schon OT

by Alfie ⌂, Vienna, Austria, Wednesday, April 03, 2019, 22:53 (1820 days ago) @ Auge
edited by Alfie, Thursday, April 04, 2019, 10:27

Hallo Auge,

Die Funktion hast du hinzugefügt?

Riecht nicht nach meinem Amateurstil. Findet sich in meiner letzten archivierten¹ Version vom April 2016. Inkl. einleitendem Kommentar:

/**
 * split of users time difference to server time
 *
 *
 * @return array $user_time_difference
 */
function processUserTimeSplit($timeDiff) {
 
if (!empty($timeDiff)
and preg_match("/^(-|\+)(([0-1][0-9])|([2][0-3])):([0-5][0-9]):([0-5][0-9])$/", $timeDiff))
 {
 $utd[0] = substr($timeDiff, 0, 1);
 $utd[1] = substr($timeDiff, 1);
 }
else
 {
 $utd[0] = "+";
 $utd[1] = "00:00:00";
 }
return $utd;
} # End: processUserTimeSplit

Dann gibt’s noch:

Warning: Illegal string offset 'admin' in D:\xampp\htdocs\bebac\forum\functions\funcs.output.php on line 367

wobei dort inerhalb von function outputAuthorsName($username, $mark, $user_id=0) die Zeile 367:

if ($mark['admin'] === 1 or $mark['mod'] === 1 or $mark['user'] === 1)
 

Kommt vor function processCountCharsInWords($string, $setting, $message), die es bei dir auch nicht gibt.

Wie lautet denn die PHP-Fehlermeldung bezüglich der oben gezeigten Funktion?

In der mix.php
Notice: Undefined variable: user_TDiff in D:\xampp\htdocs\bebac\forum\mix.php on line 204

Und dort

  while ($zeile = mysqli_fetch_assoc($threadsResult))
   {
   # read entries of thread
   $threadCompleteQuery = "SELECT
   id,
   pid,
   tid,
   user_id,
   DATE_FORMAT(time ".$post_TDiff[0]." INTERVAL '".$user_TDiff[1]."' HOUR_SECOND, '".$lang['time_format_sql']."') AS Uhrzeit,
   name,
   subject,
   category,
   marked,
   fixed,
   views
   FROM ".$db_settings['forum_table']."
   WHERE tid = ".$zeile["tid"]."
   ORDER BY time ASC";
   $rawresult = dbaseAskDatabase($threadCompleteQuery, $connid);

wobei Zeile 204 die mit den beiden $post_TDiffs ist.

Ganz oben findet sich der Verweis auf die funcs.processing.php und zwar:

 # Variablen korrekt (de)initialisieren
 unset($parent_array);
 unset($child_array);
 $post_TDiff = processUserTimeSplit($_SESSION[$settings['session_prefix'].'user_time_difference']);

Dann gibt’s noch:
Warning: Illegal string offset 'admin' in D:\xampp\htdocs\bebac\forum\functions\funcs.output.php on line 367

Und dort innerhalb von function outputAuthorsName($username, $mark, $user_id=0) die Zeile 367:

if ($mark['admin'] === 1 or $mark['mod'] === 1 or $mark['user'] === 1)

Na gut, sind notices und warnings, die offensichtlich die Funktion nicht beinträchtigen. Wenn nicht zu lösen, schmeiss ich diese Abschnitte halt raus.²

Was ich aber nicht raffe, ist das Login-Problem. Dort scheint alles in Butter zu sein, isses aber nicht. Es wird $lang['login_failed_marking'] geschmissen.
Wenn ich mich mit der Brechstange in mlf_useronline eintrage, wird unten „1 registered” angezeigt, aber oben prangt noch immer „Log in” statt meines Names und „Log out”. Krank.

[image]

Fast schon paranoid: MD5 von meinem Passwort erstellt. Stimmt mit dem Eintrag in mlf_userdata überein.

--
¹ Anlässlich Rechnerumzug offensichtlich ältere entsorgt. Motto „Schnee von gestern”. :-(

² Ich vermute, dass das mit meinen (unseren?) – erfolglosen –Versuchen zu Lokalzeiten der Benutzer zu tun hatte. Neu:

   $threadCompleteQuery = "SELECT
   id, pid, tid, user_id,
   DATE_FORMAT(time, '".$lang['time_format_sql']."') AS Uhrzeit,
   name, subject, category, marked, fixed, views
   FROM ".$db_settings['forum_table']."
   WHERE tid = ".$zeile["tid"]."
   ORDER BY time ASC";

Zeigt mir alles in der Lokalzeit an, auch wenn ich die Zeitdifferenz im Profil ändere. Ein Problem weniger.

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

Avatar

fast schon OT

by Alfie ⌂, Vienna, Austria, Thursday, April 04, 2019, 16:24 (1820 days ago) @ Alfie
edited by Alfie, Thursday, April 04, 2019, 21:38

Weiter im Erlebnisaufsatz.

2. Problem gelöst. Zufälligerweise hatte jemand auf einen Post von anno dunnemal (2007!) geantwortet und ihn damit auf die Hauptseite gehievt. Der Originalposter ist inzwischen gelöscht und es gibt keine verwertbare user_id mehr (OK, die Abfrage setzt in diesem Fall user_id=0). Daher läuft der Teil in der func.output.php der für die Auszeichnung (admin, mod, user) zuständig ist, ins Leere. Abhilfe bei mir (ich habe nur registrierte user und „Leichen”):

function outputAuthorsName($username, $mark, $user_id=0) {
 global $settings, $lang;
 $r = '';
 $name = '<span class="';
 $regimg = '';
 if (is_array($mark)) { # deleted user has no user_id any more!
  if ($mark['admin'] === 1 or $mark['mod'] === 1) {
   if ($mark['admin'] === 1) {
    $name .= 'admin-highlight" title="'.outputLangDebugInAttributes($lang['ud_admin']);
   } else {
    $name .= 'mod-highlight" title="'.outputLangDebugInAttributes($lang['ud_mod']);
   }
  }
 }
 $name .= '">'.htmlspecialchars($username).'</span>';
 # remaining lines not touched.

Manchmal ist eine Operation am offenen Herzen lehreich. Zumindest ich hätte in einem Testforum nicht daran gedacht einen User zu löschen…

@Auge: Zum each() (deprecated since 7.2.0) habe ich dir auf GitHub geschrieben.

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

Avatar

MLF1 unter PHP 7.2.17 und es läuft (nach erstem Augenschein)

by Auge ⌂, Sunday, April 07, 2019, 21:01 (1817 days ago) @ Alfie

Hallo

Ich habe den aktuellen Entwicklungsbranch v1.7.8 als Neuinstallation nach einigem Hickhack (dazu gleich mehr) unter PHP 7.2.17 mit MySQL 5.7.25 erfolgreich installieren können. Ich kann mich – diese Info richtet sich speziell an Alfie – auch im Forum anmelden. Dazu, ob ein Update mit dem aktuellen Code durchführbar ist, kann ich momentan nichts sagen.

Allerdings gibt es noch ein paar Dinge zu berichtigen, denn das Adminmenü empfängt mich mit einem PHP-Error und während der Installation sind gleich mehrere Inkonsistenzen in den Tabellendefinitionen hochgekommen (diverse Felder ohne Default-Wert, die während der Installation angesprochen aber dabei nicht befüllt werden).

Nachdem ich das behoben hatte, ließ sich das Forum installieren. Die Korrekturen sind noch nicht im Repository enthalten. Ich muss noch alle Funktionen ausprobieren, bevor ich das als Entwicklungsstand freigeben kann.

@Alfie: Da ich nun bestätigen kann, dass MLF1 unter PHP 7.2 grundsätzlich und inklusive Login funktioniert, muss diesbezüglich bei dir noch etwas anderes im Argen liegen.

Tschö, Auge

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

Avatar

MLF1 unter PHP 7.2.17 und es läuft (nach erstem Augenschein)

by Alfie ⌂, Vienna, Austria, Monday, April 08, 2019, 12:41 (1816 days ago) @ Auge

Hallo Auge,

Ich habe den aktuellen Entwicklungsbranch v1.7.8 als Neuinstallation nach einigem Hickhack (dazu gleich mehr) unter PHP 7.2.17 mit MySQL 5.7.25 erfolgreich installieren können.

Gratulation!

Ich kann mich – diese Info richtet sich speziell an Alfie – auch im Forum anmelden.

Ich inzwischen auch. Irgendwo vergessen einen Parameter zu übergeben.

@Alfie: Da ich nun bestätigen kann, dass MLF1 unter PHP 7.2 grundsätzlich und inklusive Login funktioniert, muss diesbezüglich bei dir noch etwas anderes im Argen liegen.

Das tut es. Durch meine Verschlimmbesserungen zwickt’s noch hier und dort. Die meisten Probleme sind lustig (etwa wenn ich Seiten blättere, wird in der useronline eine neue Zeile angefügt), andere ätzend (beim Speichern des persönlichen Profils landet alles ausser der Mehl-Addresse im Daten-Orkus).

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

Avatar

MLF1 unter PHP 7.2.17 und es läuft (nach erstem Augenschein)

by Auge ⌂, Monday, April 08, 2019, 12:56 (1816 days ago) @ Alfie

Hallo Alfie

Ich habe den aktuellen Entwicklungsbranch v1.7.8 als Neuinstallation nach einigem Hickhack (dazu gleich mehr) unter PHP 7.2.17 mit MySQL 5.7.25 erfolgreich installieren können.


Gratulation!

Danke. :-) Die nötigen Korrekturen sind im Übrigen doch recht umfangreich. Im Installationsskript handelte es sich nur vier oder fünf Stellen. Ich finde aber aktuell hier und da weitere Probleme. Neben Parserfehlern wegen falsch gesetzen Klammern, die beim copy'n'paste zustandekamen, ist wohl das auffällgste Problem, dass ich kein Posting speichern kann. Das Skript posting.php wirft einen MySQL-Error, was mich vermuten lässt, dass der Query eine unegale Anzahl von Feldern speichern will oder an irgendeiner Stelle ein Anführungszeichen zu wenig oder zu viel da ist.

Das zu ergründen braucht Zeit und Ruhe. Die Im Laufe der Zeit in der 1.8-er Beta mit viel Fleißarbeit erstellte recht übersichtliche Formatierung habe ich ja im neuen Entwicklungsbranch nicht mehr.

Ich kann mich – diese Info richtet sich speziell an Alfie – auch im Forum anmelden.


Ich inzwischen auch. Irgendwo vergessen einen Parameter zu übergeben.

Hmmpf …

@Alfie: Da ich nun bestätigen kann, dass MLF1 unter PHP 7.2 grundsätzlich und inklusive Login funktioniert, muss diesbezüglich bei dir noch etwas anderes im Argen liegen.


Das tut es. Durch meine Verschlimmbesserungen zwickt’s noch hier und dort.

Ich hoffe, du kannst die Probleme lösen. Wenn Fragen aufkommen, frag' (auch) hier.

Tschö, Auge

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

Avatar

MLF1 unter PHP 7.2.17 und es läuft (nach erstem Augenschein)

by Alfie ⌂, Vienna, Austria, Monday, April 08, 2019, 20:56 (1816 days ago) @ Auge

Hallo Auge,

Neben Parserfehlern wegen falsch gesetzen Klammern, die beim copy'n'paste zustandekamen, ist wohl das auffällgste Problem, dass ich kein Posting speichern kann. Das Skript posting.php wirft einen MySQL-Error, was mich vermuten lässt, dass der Query eine unegale Anzahl von Feldern speichern will oder an irgendeiner Stelle ein Anführungszeichen zu wenig oder zu viel da ist.

Welcome to the club. Ich kann zwar posten, aber anstatt des Posts prangt [ No text ] (aus der english.php $lang['no_text']). Nich so doll.
Einen MySQL-Error bekomme ich dzt. in der forum_entry.php. ☠

Das zu ergründen braucht Zeit und Ruhe.

Jepp.

Die Im Laufe der Zeit in der 1.8-er Beta mit viel Fleißarbeit erstellte recht übersichtliche Formatierung habe ich ja im neuen Entwicklungsbranch nicht mehr.

Especially wohl dein hübscher tabbed Admin-Bereich.

Das tut es. Durch meine Verschlimmbesserungen zwickt’s noch hier und dort.


Ich hoffe, du kannst die Probleme lösen. Wenn Fragen aufkommen, frag' (auch) hier.

Gern, aber nur in größter Not. Noch bin ich optimistisch.

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

Avatar

MLF1 unter PHP 7.2.17 und es läuft (nach erstem Augenschein)

by Auge ⌂, Tuesday, April 09, 2019, 07:08 (1815 days ago) @ Alfie

Hallo Alfie

Ich kann zwar posten, aber anstatt des Posts prangt [ No text ] (aus der english.php $lang['no_text']). Nich so doll.
Einen MySQL-Error bekomme ich dzt. in der forum_entry.php. ☠

Wird dir mehr als nur "Es ist ein Fehler in der Datenbank aufgetreten" angezeigt? Ich musste erst die Fehlerausgabe erweitern, um an den echten Fehler zu kommen. Für mich riecht das nach dem schon beschriebenen Problem mit den fehlenden Default-Werten. Vielleicht reagiert dein Server nicht ganz so rigoros wie der meine, der den Datensatz erst gar nicht speichert.

Die Im Laufe der Zeit in der 1.8-er Beta mit viel Fleißarbeit erstellte recht übersichtliche Formatierung habe ich ja im neuen Entwicklungsbranch nicht mehr.


Especially wohl dein hübscher tabbed Admin-Bereich.

Ja ;-) aber das meinte ich nicht. Mir ging es um die Quellcode-Formatierung, die für erheblich mehr Übersicht sorgte.

Das tut es. Durch meine Verschlimmbesserungen zwickt’s noch hier und dort.


Ich hoffe, du kannst die Probleme lösen. Wenn Fragen aufkommen, frag' (auch) hier.


Gern, aber nur in größter Not. Noch bin ich optimistisch.

Toi, toi, toi.

Tschö, Auge

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

Avatar

7.3.3 ⇔ 5.2.6

by Alfie ⌂, Vienna, Austria, Sunday, April 14, 2019, 10:34 (1810 days ago) @ Auge

Hallo Auge

Wenn Fragen aufkommen, frag' (auch) hier.

Ich muss doch noch einmal anklopfen. Zwar nur eine “Notice”, aber ich würde gerne verstehen warum.

funcs.output.php

/**
 * detects the status of $mark dependent of users role
 *
 * @param array $mark
 * @param string $user_type
 * @param string $connid
 * @return array $mark
 */
function outputStatusMark($mark, $user_type = '', $connid) {
global $settings;
 if (is_array($mark)) {
  $mark['admin'] = ($user_type === "admin" && $settings['admin_mod_highlight'] == 1) ? 1 : 0;
  $mark['mod'] = ($user_type === "mod" && $settings['admin_mod_highlight'] == 1) ? 1 : 0;
  $mark['user'] = ($user_type === "user" && $settings['user_highlight'] == 1) ? 1 : 0;
 } else {
  $mark = array('admin' => 0, 'mod' => 0, 'user' => 0); # deleted user has no user_id any more
 }
 return $mark;
}

mix.php

   # generate output of thread lists
   # highlight mods, admins and users:
   if (!empty($zeile['user_type']))
    { // account active
     if ($settings['admin_mod_highlight'] == 1 or $settings['user-highlight'] == 1)
      {
       $markA = outputStatusMark($mark, $zeile['user_type'], $connid); # Notice: Undefined variable: mark
      }
    }
   else
    { // workaround: otherwise, deleted user becomes admin
     $markA = '';
    }


Diese Notice bekomme ich unter 5.2.6 aber nicht unter 7.3.3.

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

Avatar

7.3.3 ⇔ 5.2.6

by Auge ⌂, Sunday, April 14, 2019, 19:46 (1810 days ago) @ Alfie

Hallo Alfie

mix.php

   # generate output of thread lists
# highlight mods, admins and users:
if (!empty($zeile['user_type']))
{ // account active
if ($settings['admin_mod_highlight'] == 1 or $settings['user-highlight'] == 1)
{
$markA = outputStatusMark($mark, $zeile['user_type'], $connid); # Notice: Undefined variable: mark
}
}


Diese Notice bekomme ich unter 5.2.6 aber nicht unter 7.3.3.

Grundsätzlich fehlt laut meinem Code die Initialisierung des Arrays $mark. Da das Array zum Zeitpunkt des Funktionsaufrufs nicht existiert (laut dem letzten Stand des Codes im dev-Branch, von dem deine Version irgendwann abgespalten wurde), wird die Notice erzeugt. Undzwar sowohl dort, wo du den Fehler gemeldet bekommst, also auch in der board.php (die du nicht benutzt) und der forum.php. Zudem fehlt sie in der board_entry.php für das Eröffnungsposting, mix_entry.php völlig und in der forum_entry.php dann, wenn der Ersteller des Postings nicht registriert ist. In der board_entry.php kannst du dir in der Schleife für die Antworten ansehen, wie es aussehen sollte.

Warum PHP 7.3 die Notice nicht wirft, kann ich dir aber nicht sagen.

Tschö, Auge

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

Avatar

7.3.3 ⇔ 5.2.6

by Alfie ⌂, Vienna, Austria, Monday, April 15, 2019, 08:40 (1809 days ago) @ Auge

Hallo Auge,

danke für die Hilfe!

Grundsätzlich fehlt laut meinem Code die Initialisierung des Arrays $mark. Da das Array zum Zeitpunkt des Funktionsaufrufs nicht existiert (laut dem letzten Stand des Codes im dev-Branch, von dem deine Version irgendwann abgespalten wurde), wird die Notice erzeugt.

Fehlt schon in der gemeinsam gebastelten Version vom 1. Juni 2011. ;-)

Warum PHP 7.3 die Notice nicht wirft, kann ich dir aber nicht sagen.

Ist seltsam.

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

Avatar

7.3.3 ⇔ 5.2.6

by Auge ⌂, Monday, April 15, 2019, 10:15 (1809 days ago) @ Alfie

Hallo Alfie

Grundsätzlich fehlt laut meinem Code die Initialisierung des Arrays $mark. Da das Array zum Zeitpunkt des Funktionsaufrufs nicht existiert (laut dem letzten Stand des Codes im dev-Branch, von dem deine Version irgendwann abgespalten wurde), wird die Notice erzeugt.


Fehlt schon in der gemeinsam gebastelten Version vom 1. Juni 2011. ;-)

Nun, warum auch nicht (sozusagen)? Ich bin nicht davon ausgegangen, das in deiner Version drin gehabt und später raus genommen zu haben. :-)

Warum PHP 7.3 die Notice nicht wirft, kann ich dir aber nicht sagen.


Ist seltsam.

Ich kann im PHP-Handbuch auch nichts finden, was auf die Ursache dafür hinweist. Ich hätte dort eine Anmerkung a la "Dies und das löst seit PHP 7.x keine NOTICE mehr aus." erwartet (oder so).

Tschö, Auge

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

Avatar

7.3.3 ⇔ 5.2.6

by Alfie ⌂, Vienna, Austria, Wednesday, April 17, 2019, 14:06 (1807 days ago) @ Auge

Hallo Auge

Ich kann im PHP-Handbuch auch nichts finden, was auf die Ursache dafür hinweist. Ich hätte dort eine Anmerkung a la "Dies und das löst seit PHP 7.x keine NOTICE mehr aus." erwartet (oder so).

Jenau.

Ich stöbere immer wieder mal in deinem Code. Dort hast du eine Schleife von –24 bis +24 eingerichtet. Das führt zu einem elendslangen Dropdown-Feld. Zeitdifferenzen können nur von UTC –12h bis +14h reichen.

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

Avatar

Versatz der Benutzerzeit zur Forumszeit, Zeitzonen

by Auge ⌂, Wednesday, April 17, 2019, 18:51 (1807 days ago) @ Alfie

Hallo Alfie

Ich stöbere immer wieder mal in deinem Code. Dort hast du eine Schleife von –24 bis +24 eingerichtet. Das führt zu einem elendslangen Dropdown-Feld. Zeitdifferenzen können nur von UTC –12h bis +14h reichen.

Das trifft nach aktueller Lage zu und war, wenn ich mich recht erinnere, auch schon so, als wir 2010 über die Implementierung von Zeitzonen nachdachten. Ob erst ich dieses Dropdown so eingerichtet habe, oder schon Alex, ist egal. Es sollte nach heutigem Stand nur und ausschließlich die Auswahl von Zeitzonen geben. Kein Dropdown von -24h bis +24h aber auch keines von –12h bis +14h. Wir wissen, dass es Zeitzonen mit halben oder dreiviertel Stunden Versatz gibt, von den unterschiedlichen Sommerzeitschaltungen gar nicht zu reden. Da ist alles andere als eine Auswahl aus den realen Zeitzonen Mumpitz, auch wenn das Dropdown dadurch gewiss nicht kürzer wird.

Tschö, Auge

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

Avatar

Versatz der Benutzerzeit zur Forumszeit, Zeitzonen

by Alfie ⌂, Vienna, Austria, Thursday, April 18, 2019, 15:12 (1806 days ago) @ Auge

Hallo Auge

Das trifft nach aktueller Lage zu und war, wenn ich mich recht erinnere, auch schon so, als wir 2010 über die Implementierung von Zeitzonen nachdachten. Ob erst ich dieses Dropdown so eingerichtet habe, oder schon Alex, ist egal.

Alex.

Es sollte nach heutigem Stand nur und ausschließlich die Auswahl von Zeitzonen geben. […] Da ist alles andere als eine Auswahl aus den realen Zeitzonen Mumpitz, auch wenn das Dropdown dadurch gewiss nicht kürzer wird.

Schon klar. Meine aktuelle Liste hat 408 Einträge. ;-)

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

Avatar

Probleme mit den alten Tabellendefintionen von MLF1

by Auge ⌂, Monday, April 08, 2019, 19:17 (1816 days ago) @ Alfie

Hallo Alfie

Mittlerweile habe ich einige Probleme aufgespürt, die eventuell aus den etwas altertümlichen Tabellendefintionen im Zusammenspiel mit (einigermaßen) aktuellen MySQL-Versionen herrühren.

Schon während der Installation wurden bei den ersten INSERTS (Admin-Account, Smileys) Fehlende Default-Werte für einige Tabellenspalten moniert, in die bei diesen INSERTs kein Eintrag erfolgte. Das gleiche Problem hatte ich nunmehr auch bei der Postingtabelle, wo bei einem neuen Posting das Feld "edited" leer bleibt aber eben auch keinen default value hat. Ist dir über die Jahre soetwas schon einmal untergekommen?

Für die bisher gefundenen Fälle habe ich bei den Zeitstempeln in der Eintrags- und der Benutzerdatentabelle NULL zugelassen und als Default gesetzt sowie in Falle der Spalte "title" in der Smiley-Tabelle den Default-Wert als einen leeren String ('') definiert.

Ich tendiere zudem dazu, so ziemlich alle Spaltendefinitionen mit NOT NULL default '' gegen NULL default NULL zu ersetzen. Wenn ein Feld keinen Wert haben sollte, sollte das dazugehörige Tabellenfeld auch tatsächlich leer sein und ncht einen Leerstring enthalten. Ich werde die Auswirkungen dieser Änderung mit Beispieldaten aus meinem alten Projektforum testen. Die liegen zum Glück noch in der Datenbank meiner anderen Seite.

Tschö, Auge

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

Avatar

Probleme mit den alten Tabellendefintionen von MLF1

by Alfie ⌂, Vienna, Austria, Monday, April 08, 2019, 22:23 (1815 days ago) @ Auge

Hallo Auge

Mittlerweile habe ich einige Probleme aufgespürt, die eventuell aus den etwas altertümlichen Tabellendefintionen im Zusammenspiel mit (einigermaßen) aktuellen MySQL-Versionen herrühren.

Kann gut sein. Ich denke, das Problem ist ein grundsätzliches. PHP ist schwach typisiert: Ohne vorherigige Spezifikation sind Variablen vom Typ mixed und können (!) on-the-fly umgewandelt werden. Ob das immer so funktioniert wie erwartet, ist nicht garantiert. Solange man nur innerhalb von PHP unterwegs ist, kann mich sich daran gewöhnen oder – vermutlich besser – sich selbst den Zwang auferlegen Variablen eines bestimmten Typs zu initialisieren. get_defined_vars() hat mir schon manchmal die Augen geöffnet.
Mühsam wird’s im Zusammenspiel mit einer stark typisierten Sprache wie SQL. Das ist vermutlich ein guter Teil der Schnitzeljagd die wir da betreiben.

Fehlende Default-Werte für einige Tabellenspalten moniert, […] Das gleiche Problem hatte ich nunmehr auch bei der Postingtabelle, wo bei einem neuen Posting das Feld "edited" leer bleibt aber eben auch keinen default value hat. Ist dir über die Jahre soetwas schon einmal untergekommen?

Maybe. Can’t remember. In einigen neuen Tabellen (die es bei dir nicht gibt) habe ich immer einen Default vorgegeben. Wenn nicht sinnvoll, immer NULL (auch bei varchar). Wie hat denn deine Tabelle ausgesehen? Bei mir haben last_answer und edited den Default 0000-00-00 00:00:00, NULL ist nicht erlaubt.

Für die bisher gefundenen Fälle habe ich bei den Zeitstempeln in der Eintrags- und der Benutzerdatentabelle NULL zugelassen und als Default gesetzt …

Musst du dann aber entsprechend in PHP behandeln. Aber was sag ich dir da. ;-)
Das da

<?php
 $a0 = '-0.5';
 $b0 = '+0.5';
 $a1 = $a0; settype($a1, 'integer');
 $b1 = $b0; settype($b1, 'integer');
 $a2 = $a0; settype($a2, 'float');
 $b2 = $b0; settype($b2, 'float');
 $a3 = $a2; settype($a3, 'integer');
 $b3 = $b2; settype($b3, 'integer');
 $a4 = round($a2, 0);
 $b4 = round($b2, 0);
 echo '<pre>';
 echo $a0."\n";
 echo $b0."\n\n";
 echo $a1."\n";
 echo $b1."\n\n";
 echo $a2."\n";
 echo $b2."\n\n";
 echo $a3."\n";
 echo $b3."\n\n";
 echo $a4."\n";
 echo $b4."\n";
 echo '</pre>';
?>

ist sowieso gewöhnungsbedüftig. Die kaufmännische Rundung (wie in bloody Excel, dammit!) ist einer Programmiersprache nicht würdig. Noch nie von IEEE 754 gehört?

… sowie in Falle der Spalte "title" in der Smiley-Tabelle den Default-Wert als einen leeren String ('') definiert.

Lustig. Hab ich irgendwann auch so eingerichtet.

Ich tendiere zudem dazu, so ziemlich alle Spaltendefinitionen mit NOT NULL default '' gegen NULL default NULL zu ersetzen. Wenn ein Feld keinen Wert haben sollte, sollte das dazugehörige Tabellenfeld auch tatsächlich leer sein und ncht einen Leerstring enthalten.

Ist sauberer. NULL ist NULL, basta! Ein Leerstring ist Quatsch.

Ich werde die Auswirkungen dieser Änderung mit Beispieldaten aus meinem alten Projektforum testen. Die liegen zum Glück noch in der Datenbank meiner anderen Seite.

Good luck!

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

Avatar

Probleme mit den alten Tabellendefintionen von MLF1

by Auge ⌂, Tuesday, April 09, 2019, 06:47 (1815 days ago) @ Alfie

Hallo Alfie

Mittlerweile habe ich einige Probleme aufgespürt, die eventuell aus den etwas altertümlichen Tabellendefintionen im Zusammenspiel mit (einigermaßen) aktuellen MySQL-Versionen herrühren.


Kann gut sein. Ich denke, das Problem ist ein grundsätzliches. PHP ist schwach typisiert … Mühsam wird’s im Zusammenspiel mit einer stark typisierten Sprache wie SQL. Das ist vermutlich ein guter Teil der Schnitzeljagd die wir da betreiben.

Zumindest hier spielt das keine Rolle. Die Tabellendefinitionen verzichten an verschiedenen Stellen tatsächlich darauf, einen Default-Wert vorzugeben (Beispiel weiter unten). Das fällt mir bei den Tests immer wieder auf die Füße, weil der MySQL-Server meines Webspaces so eingestellt ist, dass Datensätze, die für Spalten ohne Default-Wert selbst keinen Wert mitbringen, eine Fehlermeldung auslösen und nicht gespeichert werden.

Der Server hat aber wegen seiner Einstellungen auch schon bei der Installation des MLF2-Forums unter projekt-mlf.de hier und da gezickt.

Fehlende Default-Werte für einige Tabellenspalten … Ist dir über die Jahre soetwas schon einmal untergekommen?


In einigen neuen Tabellen (die es bei dir nicht gibt) habe ich immer einen Default vorgegeben. Wenn nicht sinnvoll, immer NULL (auch bei varchar).

Klar, wie du selbst später sagtest, NULL ist NULL. Das gilt natürlich auch für (nicht vorhandene) Zeichenketten.

Wie hat denn deine Tabelle ausgesehen?

CREATE TABLE forum_entries (
  id INT(11) NOT NULL AUTO_INCREMENT,
  pid INT(11) NOT NULL DEFAULT '0',
  tid INT(11) NOT NULL DEFAULT '0',
  uniqid VARCHAR(255) NOT NULL DEFAULT '',
  TIME TIMESTAMP NOT NULL,                  /* hier … */
  last_answer TIMESTAMP NOT NULL,           /* … und hier … */
  edited TIMESTAMP NOT NULL,                /* … und hier */
  edited_by VARCHAR(255) NOT NULL DEFAULT '',
  user_id INT(11) DEFAULT '0',
  name VARCHAR(255) NOT NULL DEFAULT '',
  subject VARCHAR(255) NOT NULL DEFAULT '',
  category INT(11) NOT NULL DEFAULT '0',
  email VARCHAR(255) NOT NULL DEFAULT '',
  hp VARCHAR(255) NOT NULL DEFAULT '',
  place VARCHAR(255) NOT NULL DEFAULT '',
  ip VARCHAR(255) NOT NULL DEFAULT '',
  text text NOT NULL,
  show_signature tinyint(4) DEFAULT '0',
  email_notify tinyint(4) DEFAULT '0',
  marked tinyint(4) DEFAULT '0',
  locked tinyint(4) DEFAULT '0',
  fixed tinyint(4) DEFAULT '0',
  views INT(11) DEFAULT '0',
  PRIMARY KEY (id),
  UNIQUE KEY id (id),
  KEY tid (tid),
  KEY category (category),
  KEY pid (pid),
  KEY fixed (fixed)
);

Bei mir haben last_answer und edited den Default 0000-00-00 00:00:00, NULL ist nicht erlaubt.

Hmm, ein nicht vorhandener Datumswert ist aber auch nur nicht vorhanden. In den Datenbanken bei mir auf Arbeit (MS SQL und MySQL) wird ein solcher „Nichtwert“ konsequent auf NULL gesetzt.

Für die bisher gefundenen Fälle habe ich bei den Zeitstempeln in der Eintrags- und der Benutzerdatentabelle NULL zugelassen und als Default gesetzt …


Musst du dann aber entsprechend in PHP behandeln. Aber was sag ich dir da. ;-)

Tatsächlich muss ich das in diesem Kontext nicht. Jedenfalls nicht, um den Datentyp sicherzustellen. Mit den gegenwärtigen Verfahren, einen Querystring zu erzeugen, sind schlussendlich alle Werte Strings. Sicherstellen muss ich nur, dass in der Datenbank die Werte den Spaltentypen entsprechend ankommen und dass die Transportmaskierungen passen.

… sowie in Falle der Spalte "title" in der Smiley-Tabelle den Default-Wert als einen leeren String ('') definiert.


Lustig. Hab ich irgendwann auch so eingerichtet.

Sauberer ist allerdings NULL, als Hotfix geht '' aber durch.

Ich tendiere zudem dazu, so ziemlich alle Spaltendefinitionen mit NOT NULL default '' gegen NULL default NULL zu ersetzen.


Ist sauberer. NULL ist NULL, basta! Ein Leerstring ist Quatsch.

Ebenst.

Tschö, Auge

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

Avatar

Ergänzung zum Vorposting

by Auge ⌂, Wednesday, April 17, 2019, 09:42 (1807 days ago) @ Auge

Hallo

War ein langer Weg. UTF-8, HTML5, CSS-Sprites, Bildchen/JS/CSS von Cookie-freier Domain, TLS, …
Nö, ein responsive design werd’ ich mir nie antun. Da können die Google Webmaster Tools noch so sehr meckern.


Wenn du ein responsives Desing benutzt, tust du das für deine Benutzer und nicht für irgendwelche Webmastertools. Zumal gerade Google an dieser Stelle kein neutraler Bewerter ist, die wollen den Seitenbetreibern für eine eventuell bessere Position in den Suchergebnislisten ihre eigenen Techniken unterjubeln, mit denen sie den Traffic kontrollieren und damit die Daten der Besucher mitlesen können.

Als ich das vorige Posting schrieb, habe ich nach dem einen Beispiel eines Google-Projekts gesucht, das sie versuchen, den Webseitenbetreibern mit der Versprechung schnellerer Seiten regelrecht unterzujubeln, ohne den Pferdefuß des Datenabzugs und der teilweisen Abgabe der Kontrolle über die eigene Seite auch nur zu erwähnen. Nun ist es mir wieder begegnet, Accelerated Mobile Pages oder kurz: AMP.

Das zur Dokumentation.

Tschö, Auge

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

Avatar

Ergänzung zum Vorposting

by Alfie ⌂, Vienna, Austria, Wednesday, April 17, 2019, 10:23 (1807 days ago) @ Auge

Hallo Auge,

[…] Pferdefuß des Datenabzugs und der teilweisen Abgabe der Kontrolle über die eigene Seite […]. Nun ist es mir wieder begegnet, Accelerated Mobile Pages oder kurz: AMP.

Horror!

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

Avatar

mögliche Wege, MLF1 weiter zu betreiben

by Micha ⌂, Wednesday, April 03, 2019, 13:50 (1821 days ago) @ Alfie

Hi,

Inwischen habe ich vorsorglich begonnen, die mysql_* Funktionen durch mysqli_* zu ersetzen. Ein Fass ohne Boden. Bekäme ich nur das „Genie” in die Finger, das die Syntax umgedreht hat (zB mysql_query($query, resource) → mysqli_query(resource, $query))! Ätzend.*

Das kann ich nachvollziehen. Ich hatte es für die 2er Version umgesetzt. Ich hatte mir hierfür einen Regulären Ausdruck geschrieben. Nach dem dieser ein paar mal kontrolliert abgefeuert sinnvolle Resultate lieferte - Augen zu und durch. Bisher halten sich die Meldungen bzgl. Fehler ja in Grenzen, sodass dies wohl ganz gut geklappt hat. Nur Mut. ;-)

Viele Grüße
Micha

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

Avatar

mögliche Wege, MLF1 weiter zu betreiben

by Alfie ⌂, Vienna, Austria, Wednesday, April 03, 2019, 15:07 (1821 days ago) @ Micha

Hallo Micha,

Bekäme ich nur das „Genie” in die Finger, das die Syntax umgedreht hat (zB mysql_query($query, resource) → mysqli_query(resource, $query))!


Das kann ich nachvollziehen. Ich hatte es für die 2er Version umgesetzt.

Wie ich dort (unten) schrieb, verstehe ich warum die Entwickler das so umgesetzt haben. Ist aber päpstlicher als der Pabst.

Ich hatte mir hierfür einen Regulären Ausdruck geschrieben.

Habe ich auch in Erwägung gezogen. Wenn ein regex eine bestimmte Komplexität erreicht, wird’s für mich bald undurchschaubar. Ich verwende die Teile halt nur selten.

Nach dem dieser ein paar mal kontrolliert abgefeuert sinnvolle Resultate lieferte - Augen zu und durch. Bisher halten sich die Meldungen bzgl. Fehler ja in Grenzen, sodass dies wohl ganz gut geklappt hat. Nur Mut. ;-)

Danke! Mut kann man nicht kaufen. Inzwischen habe ich das Forum lokal unter PHP7.3.3 am laufen. Abgesehen von der Kleinigkeit, dass ich mich nicht einloggen kann und einem hartnäckigen Fehler von anno dunnemal alles bestens. ;-)

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

RSS Feed of thread