Da scheint doch noch so einiges nicht zu stimmen.
Fängt schon bei der ersten Testinstallation unter Xampp / Windows (frische Datenbank unter Mysql 4.1) an.
Installation klappt soweit bis man sich das Web ansehen kann und dann das:
Not Found
The requested URL was not found on this server.
Wenn das andere (und gerade neue) User sehen, werfen sie die CMS nach solchen Versuchen als nicht tauglich in den Papierkorb !!
0.12
-
piratos
Re: 0.12 Nachtrag
Kleiner Nachtrag:
Die CMS und die Treiber für Mysql 4.1 arbeiten nicht korrekt zusammen unter Mysql 3.XX funktioniert es so weit.
Ich habe da noch einige andere Dinge gefunden und bewerte diese sogenannte Stable als erneute Beta, da sie keineswwegs stable ist.
Die CMS und die Treiber für Mysql 4.1 arbeiten nicht korrekt zusammen unter Mysql 3.XX funktioniert es so weit.
Ich habe da noch einige andere Dinge gefunden und bewerte diese sogenannte Stable als erneute Beta, da sie keineswwegs stable ist.
Re: 0.12
scheint wohl ein Problem unter Windows zu sein. der Zugriff auf die Admin-Sektion hingegen funkioniert. Die Fehlermeldung die bei mir erscheint unter /cmsmadesimple ist ein 404 aber ohne Hinweis welche Datei fehlt (Rewrite-Problem????)
gruss
Christoph
gruss
Christoph
-
Piratos
Re: 0.12
Ursache sind nicht vorhandene und/oder ungenügende Fehlerabfangmethoden
Das ist die SQL - Formulierung
SELECT c.content_id, c.content_name, c.content_alias, c.menu_text, c.hierarchy, c.metadata, c.id_hierarchy, c.prop_names, c.modified_date AS c_date, c.cachable, t.template_id, t.encoding, t.modified_date AS t_date FROM cms_templates t INNER JOIN cms_content c ON c.template_id = t.template_id WHERE (c.content_alias = -1 OR c.content_id = -1) AND c.active = 1
Bei mir gibt es bei der Basisinstallation unter 4.1 weder ein c.content = -1 noch ein c.content_id = -1, demzufolge erfolgt eine Rückmeldung false, das aber von der CMS nicht wie erhofft ausgewertet wird.
Fazit Seite nicht gefunden Meldung 404
Das ist die SQL - Formulierung
SELECT c.content_id, c.content_name, c.content_alias, c.menu_text, c.hierarchy, c.metadata, c.id_hierarchy, c.prop_names, c.modified_date AS c_date, c.cachable, t.template_id, t.encoding, t.modified_date AS t_date FROM cms_templates t INNER JOIN cms_content c ON c.template_id = t.template_id WHERE (c.content_alias = -1 OR c.content_id = -1) AND c.active = 1
Bei mir gibt es bei der Basisinstallation unter 4.1 weder ein c.content = -1 noch ein c.content_id = -1, demzufolge erfolgt eine Rückmeldung false, das aber von der CMS nicht wie erhofft ausgewertet wird.
Fazit Seite nicht gefunden Meldung 404
-
piratos
Re: 0.12
Also der Fehler liegt bei der CMS selbst, sie haut die Connectionid zur Datenbank weg und versucht dann mit einem 0 Wert weiter zu arbeiten.
Hier der erfolglose Versuch sich unter Mysqli als Admin anzumelden:
Warning: mysqli_real_escape_string() expects parameter 1 to be mysqli, null given in I:\xampp\htdocs\012\lib\adodb_lite\adodbSQL_drivers\mysqli\mysqli_driver.inc on line 171
Das ist die Zeile:
return "'" . mysqli_real_escape_string($this->connectionId, $string) . "'";
Dazu muss ich bemerken, dass Adodb Lite (ohne cmsms) ansonsten einwandfrei funktioniert und auch die von Adodb Lite mitgelieferten Testprogramme funzen sauber.
Hier der erfolglose Versuch sich unter Mysqli als Admin anzumelden:
Warning: mysqli_real_escape_string() expects parameter 1 to be mysqli, null given in I:\xampp\htdocs\012\lib\adodb_lite\adodbSQL_drivers\mysqli\mysqli_driver.inc on line 171
Das ist die Zeile:
return "'" . mysqli_real_escape_string($this->connectionId, $string) . "'";
Dazu muss ich bemerken, dass Adodb Lite (ohne cmsms) ansonsten einwandfrei funktioniert und auch die von Adodb Lite mitgelieferten Testprogramme funzen sauber.
-
Piratos
Re: 0.12
Der gesamte Sourcecode ist mit zig Eintragungen in der Art -- showmem('including page.functions.php'); --gespickt.
Es diente mal der Ermittlung und dem Fortschritt des Speicherverbrauches.
Die Funktion ist in lib misc.functions.php wie folgt definiert:
function showmem($string = '')
{
#var_dump($string . ' -- ' . memory_get_usage());
}
Auch wenn die eigentliche Aktion auskommentiert wurde, wird die Funktion aufgerufen und kostet somit Zeit.
Völlig unverständlich, das man diesen Datenmüll nicht entfernt hat, insbesondere dann, wenn man an der Geschwindigkeit schrauben wollte.
Es diente mal der Ermittlung und dem Fortschritt des Speicherverbrauches.
Die Funktion ist in lib misc.functions.php wie folgt definiert:
function showmem($string = '')
{
#var_dump($string . ' -- ' . memory_get_usage());
}
Auch wenn die eigentliche Aktion auskommentiert wurde, wird die Funktion aufgerufen und kostet somit Zeit.
Völlig unverständlich, das man diesen Datenmüll nicht entfernt hat, insbesondere dann, wenn man an der Geschwindigkeit schrauben wollte.
-
piratos
Re: 0.12
Den Fehler, der zu vielen Cache Fehlern und Abrissen führt habe ich gefunden.
Statt einer Anleitung was zu ändern wäre gebe ich nur den Tipp, dass bei einer Einstellung in der config.php in der Form :
$config['persistent_db_conn'] = false;
die meisten Fehler in der Art (bei mir traten keine mehr auf) erledigt sind.
Damit können dann die User die als Stable getarnte Beta mal ausführlich testen.
Ein Developer wird dann auch wissen, wo er zu suchen hat.
Statt einer Anleitung was zu ändern wäre gebe ich nur den Tipp, dass bei einer Einstellung in der config.php in der Form :
$config['persistent_db_conn'] = false;
die meisten Fehler in der Art (bei mir traten keine mehr auf) erledigt sind.
Damit können dann die User die als Stable getarnte Beta mal ausführlich testen.
Ein Developer wird dann auch wissen, wo er zu suchen hat.
-
piratos
Re: 0.12
Generated in 0.34511 seconds by CMS Made Simple 0.12 (cached) using 9 SQL queries
Das ist eine rund 22% bessere Geschwindigkeit, erreicht mit einfachsten Massnahmen, etwas Tipparbeit ansonsten keinerlei Funktionseingriffe oder irgend einen massiven Eingriff, also etwas, was jeder Developer machen kann.
Unter Linux ist das Ergebnis sogar noch besser.
Mysqli läuft voll ebenso Sqlite.
Fange nun an mit den operativen Eingriffen (das wird der Unterschied zwischen CMSMS und Powerweb)
Das ist eine rund 22% bessere Geschwindigkeit, erreicht mit einfachsten Massnahmen, etwas Tipparbeit ansonsten keinerlei Funktionseingriffe oder irgend einen massiven Eingriff, also etwas, was jeder Developer machen kann.
Unter Linux ist das Ergebnis sogar noch besser.
Mysqli läuft voll ebenso Sqlite.
Fange nun an mit den operativen Eingriffen (das wird der Unterschied zwischen CMSMS und Powerweb)
Re: 0.12
Why don't you just f*ck off with your arrogant and rude comments.piratos wrote: Den Fehler, der zu vielen Cache Fehlern und Abrissen führt habe ich gefunden.
Statt einer Anleitung was zu ändern wäre gebe ich nur den Tipp, dass bei einer Einstellung in der config.php in der Form :
$config['persistent_db_conn'] = false;
die meisten Fehler in der Art (bei mir traten keine mehr auf) erledigt sind.
Damit können dann die User die als Stable getarnte Beta mal ausführlich testen.
Ein Developer wird dann auch wissen, wo er zu suchen hat.
You must be a real *sshole with a lot of personal problembs.
Please stay away for good now, your comments are not productive and are very hurtfull to the people who work on this project.
Go away and STAY away this time!
Mambo sucks, that's why I am here.
Now they call it Joomla, but it still sucks!
CMSMS rules!
Now they call it Joomla, but it still sucks!
CMSMS rules!
-
Piratos
Re: 0.12
Ahh das war zu erwarten, produziert wieder das, für das sein Land weltberühmt ist, nur seine Produktion ist etwas daneben.Why don't you **** with your arrogant and rude comments.
Hat weder im dev noch im Forum oder gar durch Beisteuerung eigener Scripte jemals etwas anderes geleistet, was irgend jemand konkret weiter bringt.
Aber - man kann ihn tolerant ignorieren - es kann ja nicht jeder seine Kritik elegant formulieren.
Vielleicht orientiert er sich bei seinen Kommentaren mal am Stil der beiden Opas aus der Muppet - Show - da könnte man doch zumindest mal lachen.
Wie kann man nur so entgleisen, wenn man wie hier, nur einen klaren Hinweis erhält, wie man bequem und ohne nennenswerten Aufwand sein Problemchen umgehen kann - der Tipp ist immerhin für Nichtcoder gedacht.
Und der Aufwand bei der Korrektur erfordert einen Coder und keinen der es möchte und nicht kann.
Bei einem sehr guten Coder wie Wishy klingeln dagegen die Glocken und er weiss mit Sicherheit ganz genau wo er ändern muss.
Leute die zu nichts anderem fähig sind als mit verbalen Hammerschlägen sprich Gossenslang zu agieren sollten sich ernsthaft überlegen was sie tun, denn auch Beiträge in dieser Art im Internet sind gerichtsmässig verwertbar und die Verfolgung ist in den EU - Ländern sehr leicht.
Auch wenn ich da nicht die Absicht habe daraus etwas zu machen - mein Rechtsverdreher (und das ist mein Schwager) hat mir da gleich eine Menge Paragraphen vorgeschwätzt und einige betreffen auch den Forenbetreiber.
Also bitte Gossenslang weg und Kritik von mir aus hammerhart aber ohne Beleidigungen.
-
ThePaul
Re: 0.12
Ich hab das bei mir gemacht und es ist eher langsamer geworden.piratos wrote: Statt einer Anleitung was zu ändern wäre gebe ich nur den Tipp, dass bei einer Einstellung in der config.php in der Form :
$config['persistent_db_conn'] = false;
Vorher lag die Zeit bei 3,5s jetzt immer um die 3,6s
-
piratos
Re: 0.12
DerTipp im Zusammhang der Beiträge gelesen bezieht sich auf die Nichtfunktion von mysqli mit persistant.
Unter mysql funktionierts einwandfrei, unter mysqli eben nicht.
Hier ging es also um das nackte funktionieren, nicht um Geschwindigkeit.
Wenn persistant funktioniert ist es immer etwas schneller.
Im übigen ist der Zeitbedarf für Abfragen beim reinen Datenbankzugriff so minimal, dass sie kaum in's Gewicht fällt. 99% des Zeitaufwandes liegt bei der CMS selbst.
Und da sitzt der Zeitunhold nicht auf einem dicken Baum sondern in den meisten Fällen hinter kleinen Büschen, die den Auspuff verstopfen.
Unter mysql funktionierts einwandfrei, unter mysqli eben nicht.
Hier ging es also um das nackte funktionieren, nicht um Geschwindigkeit.
Wenn persistant funktioniert ist es immer etwas schneller.
Im übigen ist der Zeitbedarf für Abfragen beim reinen Datenbankzugriff so minimal, dass sie kaum in's Gewicht fällt. 99% des Zeitaufwandes liegt bei der CMS selbst.
Und da sitzt der Zeitunhold nicht auf einem dicken Baum sondern in den meisten Fällen hinter kleinen Büschen, die den Auspuff verstopfen.
