CMS made simple 1.8.2 "Toliara" veröffentlicht

[cyberman]

Diese Version macht hauptsächlich die mit der letzten Version erfolgte Entfernung des Parameters use_hierarchy aus der config.php rückgängig. Um den Anwendern nicht ihre Suchmaschinenoptimierung durcheinander zu bringen, haben wir diese Option wieder eingefügt.

Es wurden ein paar Fehler korrigiert, einschließlich eines Fehlers im cms_stylesheet Plugin, eines Fehlers im MenüManager und noch ein paar weitere Fehler, die schon längere Zeit offen sind.

Rückgängig gemacht:

Die Option use_hierarchy in der config.php wurde aus Gründen der Abwärtskompatibilität wieder eingefügt. Dies wird eventuell in zukünftigen Versionen entfallen, da es dadurch schwierig wird, für Module Pretty URLs zu erstellen, aber wir haben dafür Abhilfe geschaffen.

Fehlerkorrekturen:

    * 5206 Die Verwendung der Variable $this in translation.functions.php
    * 5198 Deutsche Anpassung der function.cms_selflink.php
    * 2215 Die Eingabefelder für Passwörter in Formularen sollten mit einer ID versehen sein
    * 4834 Den hidden-Eingabefeldern in Formularen eine ID hinzugefügt
    * 5279 cms_stylesheet Plugin verwendet mit dem "name"-Parameter nicht die neue Logik
    * 3620 $node->image wird bei Verwendung der Variable $item nicht angezeigt

[hlf]

Nun ja von Verbesserungen hinsichtlich PHP 5.3 keine Spur zu sehen, selbst das von mir zur Verfügung gestellte 100% E_STRICT und 5.3 fähiges Xajax nicht dabei, aber egal.

CMSMS könnte gewinnen wenn man für 5.3 User einen manuellen Eintrag in die config.php

error_reporting(0);
ini_set('display_error',0);

nicht einfach wieder bei der Installation killen würde. Mit dem Eintrag lässt sich CMSMS auch unter 5.3 E_STRICT installieren und betreiben.
Und eine
Blanko config mit diesem Eintrag wäre auch nicht schlecht.

Ernst zu nehmende Progger arbeiten immer unter E_STRICT und werden somit alles was neu ist auch so installieren und testen und jede Menge anderer Hoster haben unter 5.3 die Deprecated Meldungen aktiv und zwar bewusst und dann trifft man normale Anwender direkt in den Hintern  das lässt sich vermeiden.

Was mir noch auffällt - die Liste im Bugtracker ist nicht kleiner geworden, offenbar ist eine Meldung dort wirklich sinnlos, nur wenn man hier im Forum tüchtig kräht tut sich etwas.

[cyberman]

CMSMS könnte gewinnen wenn man für 5.3 User einen manuellen Eintrag in die config.php

error_reporting(0);
ini_set('display_error',0);

nicht einfach wieder bei der Installation killen würde. Mit dem Eintrag lässt sich CMSMS auch unter 5.3 E_STRICT installieren und betreiben.

Da gebe ich dir recht - sollte vom Installationsassistenten geschrieben werden.

Und eine Blanko config mit diesem Eintrag wäre auch nicht schlecht.

Das hatte ich schon vor langer Zeit diskutiert - war aber nicht DAU-sicher genug, insbesondere dann, wenn keine Diffs zum Aktualisieren geliefert werden. Da isses zu leicht möglich, dass ein unbedarfter/unaufmerksamer User die Blanko config über das Original bügelt.

Von daher ist die .htaccess momentan die bessere Richtung, via

Code: Select all

php_flag display_startup_errors 0
php_flag display_errors 0
php_flag html_errors 0
php_value docref_root 0
php_value docref_ext 0

lässt sich so ziemlich viel unterdrücken. Und sie wird beim Update nicht überschrieben .

[hlf]

Was mich interessiert ist die nachvollziehbare Tatsache das offenbar mit dem Bugtracker nicht ernsthaft gearbeitet wird.
Wie sonst sollte man erklären das akzeptierte Fehler teils über Jahre dort ihren Ruhestand angetreten haben und die  Liste nur dann kürzer wird, wenn irgend jemand sie einfach mal löscht.

Die Moderatoren könnten doch sich abzeichnende Fehler bzw. Beiträge aus den Foren schnappen und die in einem internen Board zur Abarbeitung posten, solange das Dinge aus dem Core- Bereich sind.

Damit wären die Dev's praktisch unter "Aufsicht" der Moderatoren und könnten aus dem Fundus auch an User berichten.

So oder ähnlich könnte man das organisieren.

Mache ich in ähnlicher Form genauso und das läuft sehr gut.

Was mich auch interessiert - was passiert mit CMSMS wenn PHP die depreciated Notice zum fatalen Error macht - damit dürfte in den näöchsten zwei PHP 5.3.X Versionen zu rechnen sein.

Dann nützen Umgehungen rein nichts mehr.

[Rolf]

@hlf

Was mir noch auffällt - die Liste im Bugtracker ist nicht kleiner geworden, offenbar ist eine Meldung dort wirklich sinnlos, nur wenn man hier im Forum tüchtig kräht tut sich etwas.

1.8.2 is released.  It puts use_hierarchy back as well as some bug fixes.

We're listening, we swear. 

Version 1.8.2 - Toliara
-----------------------------
Reverted:
  - Put the use_hierarchy config option back in for backwards compatibility
    with upgrades. This may go away in the future, as it doesn't allow for
    modules to have pretty URLs, but we'll have a proper workaround.

Fixes:
  - #5206 Using variable $this in translation.functions.php
  - #5198 German adaption in function.cms_selflink.php
  - #2215 Form Input Type of Password should have an ID attribute
  - #4834 Add an ID attribute to the form hidden tag

Version 1.8.1 - Mankara
-----------------------------
Security:
  - Fixed local inclusion security flaw

Fixes:
  - Backend is slower then previous release
  - Core modules/tabs in the backend aren't translated
  - Internet Explorer doesnt show specific backend-pages nicely (f.e. News)
  - Theme ´default´ gives message ´Undefined index: direction´ on top in backend
  - The content tag isn't allowing underscore in name of block anymore
  - Default content has News categories in summary-template
  - Added expand-collapse buttons on top of listcontent as well
  - User preferences for page-limit templates isnt taken
  - Additional blocks arent visible in editmode, when underscore is used

Version 1.8 - Madagascar
-----------------------------
Core:
  - #3255 Shortcuts in admin section should omit server name
  - #3825 Error in demo template "Top simple navigation + left subnavigation + 1 column"
  - #4016 Add Pages permission cannot be removed from new groups
  - #4211 simple_navigation.tpl broken
  -      Added Section Header in stylesheet "Navigation: Simple - Horizontal"
  - #4720 Error in class.module.inc.php
  - #4895 lang=0 versus lang="0" on cms_selflink help page
  - #4907 Content/Pages/Edit Page Content is not translated
  - #4929 Copy page - can't select section header
  - #4941 Error in Search Module
  - #4952 Alias changes if user has no permission "Manage All Content"
  - #4993 Cannot add new section header
  - #5062 Date Format String in Admin Prefs too Short
  - #5090 Print module: includetemplate parameter doesn't work
  - Fixed issue where thumbnail width and height wasnt taken.
  - Generate an error if there is no default content detected when saving
    a page, this should help with the problem of no {content} block with
    content type pages.
  - Generate unique content block names if trying to use something that
    already exists.
  - Fixes with HTTPS stuff and the secure option
  - Remove alot of long deprecated callback methods.
  - Update the phpdoc documentation
  - Removed the 'community help' links for modules.
  - re-work the lang mechanism to be smarter, and faster.
  - Remove the old 404 handler stuff
  - The {stylesheet} tag is now deprecated, use {cms_stylesheet} instead.
  - General cleanup of unused functions and methods.
 
  Feature request
  - #380 use variables in stylesheets.

News:
  - Fixed issue with sorting of articleid. 
 
MenuManager:
  - #2488 Apply and Submit does not work in certain scenario
  - #4906 Error W3C on accessible_simple_navigation.tpl
  - Adds the childrenof parameter so that you can do something like
    {menu childrenof=$page_alias}
 
CoreInstaller:
  - #4978 Fix typo in upgrade.32.to.33 script

ModuleManager
  - Many improvements.
 
Version 1.7.1 - Escada
-----------------------------
  - #3794 Remove use of readfile.
  - #3854 Problem searching multiple words
  - #3901 Forms use SERVER_NAME not HTTP_HOST, conflicts with canonical redirects
  - #4009 Modules cannot update or dont work when using SSL
  - #4138 Content Internal Page doesn't work if approched directly
  - #4032 Admin Forms won't work on https
  - #4209 Alias field is not shown for Section Header
  - #4321 cms_module action parameter by tag overwriten by mact
  - #4414 Default page becoming inactive
  - #4500 Permission "Remove Global Content Block" not working
  - #4507 Indexes not created with Database Prefix
  - #4551 OO Programming
  - #4603 ContentStylesheet is never triggered
  - #4720 Error in class.module.inc.php
  - #4779 Upgrade page displays incorrect information
  - #4838 htmlentities in current_date
  - Missing in accessible_simple_navigation.tpl
  - Adds class items to every form element for easier styling.
  - Adds user preferences for page limits in GCB, Stylesheet, and template lists.
  - Adds site preferences for thumbnail width and height, primarily used by image manager
    but may be used by other modules.
  - Fixes a VERY MINOR potential security issue in user preferences.
...
...
...
...
Und so weiter...

Vielleicht sehen wir uns beim http://geekmoot.com/2010/schedule/


Schöne Gruszen aus die Niederlände,
Rolf   

[hlf]

Rolf wenn du mal in den Bugtracker schaust findest du jede Menge Meldungen bei denen sich nichts rührt, angefangen mit einer Meldung aus 2007, einer ziemlichen Anzahl aus 2008, 2009 und einer Anzahl aus der ersten Hälfte 2010 - das sind diese Sachen die ich meine.

Das sieht so etwas von inaktiv aus.

Bugs muss man nach dem Prinzip first in first out bearbeiten, da darauf basierend sich aus Erfahrung jede Menge Meldungen auch hier im Forum ergeben.

[hlf]

.htaccess

Die vorgeschlagene htaccess funzt nicht überall:

Strict standards: Non-static method PageInfoOperations::LoadPageInfoByContentAlias() should not be called statically in /var/www/cmsms/index.php on line 117 Call Stack: 0.0075 638608 1. {main}() /var/www/cmsms/index.php:0

der Eintrag in die config jedoch schon.

[Rolf]

Rolf wenn du mal in den Bugtracker schaust findest du jede Menge Meldungen bei denen sich nichts rührt, angefangen mit einer Meldung aus 2007, einer ziemlichen Anzahl aus 2008, 2009 und einer Anzahl aus der ersten Hälfte 2010 - das sind diese Sachen die ich meine.

Das sieht so etwas von inaktiv aus.

Bugs muss man nach dem Prinzip first in first out bearbeiten, da darauf basierend sich aus Erfahrung jede Menge Meldungen auch hier im Forum ergeben.

Gewiß, es gibt alte Meldungen, aber die wichtigste Meldungen haben Priorität!
- Sicherheitslöcher
- Probleme die viele Menschen belästigen
- Usw.
Aber auch kleine typographische Fehler die leicht zu beheben sind.
"First In, First Out" ist hier einen falschen Weg zu gehen glaube ich...

Mit wenigen Leuten versuchen wir die Arbeit zu erledigen. Aber Ich werde Ihren 5.3 Vorschlag mit das Team besprechen.

Gruss, Rolf 

[hlf]

Gewiß, es gibt alte Meldungen

Prioritäten hin und her, es sollte nicht  so sein, das Meldungen 2..3 Jahre alt werden ohne erledigt zu sein, das ist auch bei einer Anzahl von Prioritätsarbeiten einfach unmöglich.

Mit wenigen Leuten versuchen wir die Arbeit zu erledigen.

Das ist natürlich immer ein Thema. Ich habe nun keine Ahnung wie viele Leute tatsächlich dran arbeiten. Vielleicht kann man sich ja besser organisieren.

[NaN]

Überlasst es bitte den Entwicklern wie sie wann welche Fehler beheben.
Organisatorische Verbesserungen wurden bereits angesprochen, jedoch darf man bitte nicht vergessen, dass das alles hier größtenteils in der Freizeit realisiert wird.

Ich finde es gut, sich den Problemen einiger User bezüglich der SEO Problematik angenommen und einen Schritt zurück gemacht zu haben.
Das zeigt, dass ein Austausch zwischen Anwendern und Entwicklern nicht nur möglich ist sondern auch Resultate hervorbringt.

Wenn es aber jemandem schon zu viel ist, einen Fehler - für den er nebenbei bemerkt bereits die Lösung hat - überhaupt zu melden, dann sollte er sich besser nicht beschweren, dass es nicht vorrangeht.

[hlf]

Seit wann ist eine Feststellung eine Beschwerde ?
Natürlich überlässt man das den Entwicklern wann sie was etwas erledigen.

Wenn man mit 2..3 Jahren rechnen darf bis man vielleicht etwas korrigiert hat, dann darf man sich auch nicht wundern, wenn User nichts mehr melden wollen.

Aber nun ist es ja gut zu wissen das es so ist, dann richtet man sich darauf ein und gut ist.

[hlf]

Wer sich das Bild mal ansieht stellt folgendes fest.
Es ist ein Auszug von phpinfo zu sehen und zwar als Preview bei einer Seitenbearbeitung.

Display_error ist On, error_reporting= volles Rohr.

CMSMS Debug ist on.

Was hier nicht zu sehen ist - Xajax - Debug ebenfalls auf On.

Was hier ebenfalls nicht zu sehen sind - irgendwelche Fehler, Warnungen, Notizen etc. .

Richtig das läuft unter PHP 5.3.3 und zwar unter E_STRICT und allen möglichen Meldungen und zwar fehlerfrei.

Aufwand für mich weniger als eine Stunde und zwischendurch gemütlich ein Käffchen nebst Keksen.

Ein paar Fehlerchen die man so entdeckt wenn man als Developer unter E_STRICT arbeitet habe ich auch entfernt.

Ich habe Cyberman die Entscheidung überlassen ob ich diese Version irgendwie als Download anbiete oder nicht.

Ansonsten ? Vielleicht Wartezeiten von 2..3 Jahren wenn PHP 5.3.X  schon obsolet ist und es bereits PHP 6.2 gibt ? Keine Ahnung, weiss ich nicht. 

[hlf]

Das Interesse scheint nicht groß zu sein eine E_STRICT Version zu bekommen.
Vielleicht liegt es daran das einige nicht sehr viel darüber wissen.

Wer unter E_STRICT programmiert oder auch nur die CMS damit laufen lässt bekommt alles angemeckert was streng genommen ein Fehler ist. E_STRICT gibt es in den aktuellen PHP 5.2.X Versionen und natürlich unter 5.3.X.
E_STRICT ist somit das Mittel für eine saubere Programmierung und das Hilfsmittel überhaupt für Progger, denn bequemer geht es nicht mehr - man bekommt alles angezeigt, was da schräg läuft.

Dieses angemeckere führt dazu, das das CMS nicht laufen oder optisch mit solchen Meldungen zerstört wird.
Es läuft lediglich und auch nur eingeschränkt wenn alles was an Fehlern in dieser Form auftritt nicht angezeigt wird - man kann das unterdrücken aber auch schon unter 5.3.2 .. 3 nicht mehr in allen Fällen.

Tritt solch ein erfolgloser Versuch z.B. bei der Nutzung von (X)Ajax auf ist Absturz angesagt.

In den nächsten Versionen von PHP 5.3.X ist damit zu rechnen, das aus den Hinweisen fatale Fehler werden, was unmittelbar zur Folge haben wird das dieses CMS absolut nicht mehr läuft, denn fatale Fehler lassen sich nicht unterdrücken.
Man kann dann CMSMS nur noch weg werfen oder auf eine alte PHP 5.2.X Version beharren, die aber ist laut PHP bereits aus der Wartung - also tot.

Nun das Dilemma verstanden ?
Die Alternativen lauten nur Ex und Hopp  oder E_STRICT.

Wer es aber unter 5.3.X in der Entwicklung schafft die zahlreichen Dinge die sich da geändert haben auszumerzen ohne das spezielle 5.3 Dinge eingesetzt werden - was normal absolut problemlos möglich ist, hat eine Version die sauber unter 5.2.X wie auch 5.3.X ja sogar mit den frühen Alphaversionen von PHP 6 einwandfrei läuft.

Das - sorry - hat noch nicht einmal Ted Kulp so richtig verstanden.

Mit anderen Worten - eine solche CMS kann noch sehr lange laufen ohne das die Verfallszeit erreicht werden wird.

Dieser Zustand ist aber aktuell überhaupt nicht gegeben.

Bei der von mir erstellten E_STRICT Version handelt es sich also um eine die dafür sorgt, das CMSMS noch lange Zeit unter 5.2.X wie auch 5.3.X laufen wird.

Die Änderungen sind in der Regel kleinere betreffen aber eine Vielzahl von Scripten und es dreht sich nur um die Core - Version nicht um die angebotenen Module oder Plugins aus dritter Hand.

Ich kann was diese Module betrifft nur bescheingen, das die meisten was künftige Lauffähigkeit betrifft in extrem schlechten Zustand sind. Da müssen die Entwickler sich mal in den Hintern treten, E_STRICT auf ihren lokalen Rechner aktivieren und ihre Dinge mal durchsehen.

Ich werde Cyberman in den nächsten 2 Tagen eine solche Version zur Verfügung stellen.
Die liegt fertig für Mysql(i) vor, ich werde sie jedoch noch hinsichtlich Mysql,Postgresql überarbeiten.

Was nun Cyberman damit anfängt, ob er  allgemein einen Link bekannt gibt oder nur selbst nutzt oder was auch immer ist seine Sache.

[hlf]

Version habe ich an Cyberman geschickt - was er daraus macht oder nicht - seine Sache.

Schätze das ich weit über 98% aller E_STRICT Dinge erwischt habe.
Ich möchte noch in dem Zusammenhang auf folgendes hinweisen:

Es werden von CMSMS einige Fremdlibs verwendet die seit vielen Jahren (teils deutlich mehr als 5) vom Autoren nicht mehr gepflegt wurden und wegen des Alters absolut nicht mehr zeitgemäß sind, weil da Funktionen nachgebildet werden, die es in 5.2 ... 5.3 direkt gibt.

Die Dev's hier müssten das wissen - kann da nur empfehlen sich drum zu kümmern.

Ansonsten endet hier meine Zusammenarbeit mit CMSMS.

[NaN]

Das ist schade.
Wachsame Augen sind immer eine große Hilfe.
Und Deine Anmerkungen sind ja auch durchaus richtig.
Aber leider scheint Geduld nicht Deine Stärke zu sein.

Wenn ich eines bei CMSms gelernt habe, dann Geduld.
Mehr als seine Kritiken und evtl. Lösungsvorschläge an den Mann zu bringen, kann man nicht tun.
Was daraus wird, ist Sache der Entwickler.

Ich möchte nicht in der Haut der Entwickler stecken.
Einerseits die lang ersehnte 2.0 entwickeln zu wollen (bei der hoffentlich alle derzeitigen Defizite ausgebügelt werden - und bei der nebenbeibemerkt Ted größtenteils alles alleine machen muss) aber andererseits auch noch "den alten Kram" auf Vordermann halten...

Das ist ein Spagat den ich wirklich niemandem zumuten möchte.

Ich habe die vage wissenschaftlich nicht fundierte Hoffnung, dass CMSms 2.0 irgendwann rauskommt und alles besser macht was jetzt noch nicht perfekt ist.

Die Entwickler haben mit der Vorraussetzung, dass E_STRICT und E_DEPRECATED abgeschaltet sind, eine für mich annehmbare Übergangslösung geschaffen, mit der die Zeit bis CMSms 2.0 überbrückt werden kann.

Ich kenne keine einzige öffentliche Webseite, die unter Entwicklerbedingungen läuft. D.h. im normalfall - und das schreibe ich jetzt zum gefühlten 1000. Mal - hat aus Sicherheitsgründen die Ausgabe von Fehlermeldungen deaktiviert zu sein. Wenn etwas nicht funktioniert, dann funktioniert es nicht. Der Webseitenbesucher muss nicht wissen warum es nicht funktioniert.

Daher sehe ich dem E_STRICT Problem sehr gelassen entgegen.
Ich bin zuversichtlich, dass es bis zu dem Zeitpunkt, an dem unter PHP 5.3.* auch alle Notices und Warnungen etc. zu Fatalen Fehlern führen, bereits eine Lösung gibt.
Und wenn diese nur "Kaffee und Kekse" bedeutet