ich habe mir gerade mal die Beta aufgespielt und fühl mich doch ohne eine grundlegende Dokumentation etwas überfordert. Wann ist denn mit einer solchen zu rechnen?
In dem Zusammenhang habe ich gleich eine grundlegende Frage zu den Templates bzw. dem Layout: ist es so, dass man in Admin > page layout gebunden ist und man das eigentliche Layout demgemäß im Verzeichnis phpwcms_template einzurichten hat?
Sehr gut und wirklich an Typo3 erinnernd ist die Möglichkeit flexibel Content in den Artikeln anzulegen. Und wirklich erste Sahne ist die automatische Skalierung von Bildern. Toll!
=============================================================================
PHPWCMS changelog
=============================================================================
2003-10-11
- GLOBAL CHANGE
php opener shortcut was changed from <?php to <?php for solving possible
future problems with php and xml
- CHANGE [article.readform.inc.php]
fixed an error in content image list where smaller images than max
width/height were not copied because of a wrong var name
- CHANGE [image_zoom.php]
disabled the little [X] CLOSE image layer - not really neccessary
also created a table where the image is centered for fixing a display
problem in Internet Explorer 5 on Macintosh
- NEW [rss.php / conf.rss.inc.php]
new file for rendering a RSS 1.0 compatible feed file of all or
only given structure level and RSS configuration file
usage: a) http://www.mysite.com/rss.php -> complete structure
b) http://www.mysite.com/rss.php?rssfeed=5 -> structure ID
c) http://www.mysite.com/rss.php?news -> structure ALIAS
[RSS INT/STRING/EMPTY]linktext[RSS] -> link like a) b) c)
{RSS} -> little RSS image
CHANGE [conf.template_default.inc.php
front.func.inc.php
content.func.inc.php]
=============================================================================
2003-10-13
- NEW [front.func.inc.php]
new random image function that returns a true HTML image tag <src img="...>
that speeds up the process the browser shows the image rather than using
the "old" random image replacement tags {RANDOM_...} where an PHP script
returns the true image data. With the new placeholder {RANDOM:path} the
browser can cache the image(s) if it was loaded once before. Another
advantage is a cleaner rendering code. You can mix now the data type of
your random image (extension: JPG, JPEG, PNG, GIF) - and the function
checks if it is really an image - if not it tries to find the next image.
usage: {RANDOM:path_to_where_the_random_images_are}
example: {RANDOM:img/my_random_images}
=============================================================================
2003-10-14
- FIX [content.func.inc.php]
Rendering of placeholder tags are changed - there was a problem when you
have use {RSS} or {DATE_LONG} within content - it was not replaced. WHY?
I do'nt know. Maybe a format problem of PHP. But now it works better!
=============================================================================
2003-10-18
- CHANGE
Path definitions. There is a renamed file db.connect.inc.php
is now default.inc.php. Now every path value is defined WITHOUT any
slashes. I have changed this also within the Setup script. The correct
adding of slashes as path's prefix or suffix will be done inside
default.inc.php every time you open a backend or frontend page. This is
more flexible and easier to understand. I also extended the setup script:
it checks if the setup.conf.inc.php is writable before writing any
configuration.
- ADD | CHANGE
Now there is a constant defined with the phpwcms root path info:
PHPWCMS_ROOT. It will be created of the new configuration value
$phpwcms["root"] and the $_SERVER['DOCUMENT_ROOT']. The $phpwcms["root"]
defines where phpwcms is installed on your webserver - it is now possible
to store phpwcms in a directory deeper than your web server root directory.
- CHANGE
I decided to rename the file "article.php" to "index.php". That is much
better - I think. "article.php" was changed in a way that hits to that
file will redirected to the "index.php". This is also better if you want
to hide the "index.php" in links - use it like this:
http://www.mydomain.com?news If you need a page loaded before phpwcms
maybe an "index.html" you can not use this - this is usable if you put
phpwcms into another directory.
=============================================================================
2003-10-20
- ADD
A new content type "code". It is used to return preformatted text.
It does not use the preformatted HTML tag <pre>BlaBlaBla</pre>. All it
makes is using a monospaced css font definition and replaces all line
wraps by <br> and every space " " will be converted to " "
=============================================================================
2003-10-21
- FIX
The db pefix var $phpwcms["db_prepend"] was changed to a constant
DB_PREPEND. That is a workaround for possible errors inside user defined
functions with db access to phpwcms tables.
- ADD | CHANGE
I have rewritten the complete block management administration. The base
work is done for a per structure level template system. There is a new
menu in Backend admin section "templates". Here you can create and edit
templates and define the default template. It will be defined just like
the old block definition - but additionally you can select a different
css file for every template (if you need this).
=============================================================================
2003-10-22
- FIX
Fixed the list_articles_summary() function a little bit. Now it links the
correct category (level structure) ID of the listed article. That makes it
possible to load the template values before the article content is
rendered. So it will be (maybe) no longer a problem to change all template
value definitions - especially the pagelayout and template configuration
values. At the moment it is not implemented to have also different
pagelayout and template configuration values for a template. This will be
realized as soon as possible.
=============================================================================
Desweiteren erarbeite ich gerade noch ein einfaches Newsletter System.
Ich habe gestern die gesamte Templateverwaltung überarbeitet. Jetzt kann für jede Struktur der Navigation ein eigenes Template erstellt werden - im Moment aber immer basierend auf dem einheitlichen Seitenraster, das weiterhin über pagelayout verwaltet wird.
Es existiert ein DEFAULT template, das immer als Basis für das home-Level dient bzw. genutzt wird, wenn der Ebene nicht explizit ein eigenes Template zugewiesen worden ist. Es können beliebig viele Templates erstellt werden. Jedem Template kann ein eignes CSS-File zugewiesen werden. Jedem Template können eigene Metadaten sowie eigene JavaScript Elemente mitgegeben werden sowie ein eigenes JavaScript onLoad.
Möchte man jetzt für jedes Template auch verschiedene Farben in der Seitenbasis erarbeiten, würde ich wie folgt vorgehen:
Nackten Seitenrahmen bauen und alle Elemente mit passendem CSS versehen - Farben, Hintergrundbilder usw. komplett per CSS verwalten oder aber den Block entsprechend mit HTML Codes auskleiden. Klingt wirr - ist aber sehr einfach zu realisieren.
Wenn die Doku steht und ich wieder etwas mehr Zeit habe, werde ich auch noch eine Variante entwickeln, bei der dann vollständig freie Templates erstellt werden können. Leider sind noch etliche Details im Moment wichtiger - aus meiner Sicht.
Klingt alles schon mal sehr gut!
Denke schon, dass ich das verstanden habe, was Du meinst und freu mich schon auf die Veröffentlichung der entsprechenden Doku bzw. Verbesserungen ...
