You are reading the Drake CMS Official Forums archive, available for historical purposes only.
Drake CMS has been rebranded into Lanius CMS, visit the new Lanius CMS Official Forums if you need support about Lanius CMS or Drake CMS -> Lanius CMS migration.
This CMS is what I want. Because our intranet system working
without relational database system. Drake supports Gladius
text-file based DB subsystem. Now I playing to translate some
resources to Japanese. I'll send my URL when I created funny site
with Drake.:-)
transdrake
Re: FANTASTIC!
05 September 2007 20:46
Anonymous
My first criteria that take me to Drake was also this. The Flat
File database.
Flat file is possible in tons of CMS's
but none of them even cant get closer to the Drakes speed,
features and flexibility.
And also nice that it nearly
needs anything but PHP Nobody cant stop it working even in free
hosts
trex1512
Re: FANTASTIC!
06 September 2007 00:35
Anonymous
Welcome..
Drake CMS can only get better from here. A
lot of time and effort by a small group of devs has reached this
far, not far to go.
The more that use and test it
now the better it will become. Heres hoping you will encourage
others to become involved..
Beware however that as it
is still in beta using it for a live site may have consequences.
Possible future changes to core files and database structures may
leave your installation orphaned and unsupported.
If
you are interested in becoming involved with translations etc
just ask.
TerryF
siedlerchr
Re: FANTASTIC!
09 September 2007 20:03
Anonymous
Quote:
Beware however that as
it is still in beta using it for a live site may have
consequences. Possible future changes to core files and database
structures may leave your installation orphaned and
unsupported.
But, aren't the DB files from older
versions compatible with newer one?
I think this
would be only a big problem, if you created an own template...
So, when I'm just using the standard template, will I
have problems?
trex1512
Re: FANTASTIC!
10 September 2007 00:09
Anonymous
Hi
Quote:
But,
aren't the DB files from older versions compatible with newer
one?
Not so much "compatable" but
routines are in place to restore backups from those earlier
versions to official releases, however as detailed in the latest
news on 0.4.6 NOT SVNs.
BUT, there is always a BUT,
while in beta and until an official release occurs caution should
be your byword re safety of your data.
Quote:
I think this would be
only a big problem, if you created an own template...
Maybe not, it would not take much to update a template
that is working OK on the latest beta releases.
Quote:
So, when I'm just
using the standard template, will I have problems?
No,..A template is a far different matter to live data that may
entail scores of users, site details, articles, news, content etc
etc.
I warn users that they are using a beta release
and to NOT rely on it on a live site.
As much as we
are very very happy with where Drake CMS is currently at in its
dev cycle, we would hate to see a user setup a live site and
start using it only to have things go awry and lose that user and
their users confidence in Drake.
The good thing now is
with the imminent release of 0.4.6 RC1 the first offical release
is not that far away.
TerryF
trex1512
Re: FANTASTIC!
10 September 2007 00:14
Anonymous
Hi Again..
Just in relation to the chat above re flat
file and speed, I have been testing using SQLite and have found
it to be very very good, speed wise it is very fast.
TerryF
legolas558
Re: FANTASTIC!
10 September 2007 10:01
Anonymous
Quote:
Quote:
But, aren't the DB
files from older versions compatible with newer one?
Not so much "compatable" but routines are in
place to restore backups from those earlier versions to official
releases, however as detailed in the latest news on 0.4.6 NOT
SVNs.
BUT, there is always a BUT, while in beta and
until an official release occurs caution should be your byword re
safety of your data.
SVN database backups
have NEVER been supported and
NEVER will be, simply because we use SVN to test
new features and also new database changes. The SVN revision is
the developers' and testers' preview.
We are instead
ALWAYS supporting the official releases'
database backups. This must be made clear once for all: there
*is* full backward compatibility, you can import
a database from a previous official Drake CMS release into a more
recent one without loosing your data.
If you are
talking about the Gladius DB database files you should be very
careful: it is not a good habit to copy over those files, unless
you track the Gladius DB version used by Drake CMS and copy them
ONLY between same Drake CMS versions.
The correct
process is to make a database backup and restore that one.
Quote:
Quote:
I think this would be
only a big problem, if you created an own template...
Maybe not, it would not take much to update a template
that is working OK on the latest beta releases.
Quote:
So, when I'm just
using the standard template, will I have problems?
No,..A template is a far different matter to live data that may
entail scores of users, site details, articles, news, content etc
etc.
I agree, templates are not related to
database data in Drake CMS
Quote:
I warn users that they are using a beta
release and to NOT rely on it on a live site.
As
much as we are very very happy with where Drake CMS is currently
at in its dev cycle, we would hate to see a user setup a live
site and start using it only to have things go awry and lose that
user and their users confidence in Drake.
Here
here here! Using a BETA for a live website is not a good thing,
not really by the data integrity point of view but by the
usability and general user experience: BETAs use to have broken
features...just because we have not yet fixed them
Quote:
The good thing
now is with the imminent release of 0.4.6 RC1 the first offical
release is not that far away.
TerryF
Exact, the next release will be Drake CMS v0.4.6 RC1, which is
still a Beta but also a "Release Candidate": we will no
more add features and stabilize the current ones.
legolas558
Re: FANTASTIC!
10 September 2007 10:03
Anonymous
Quote:
I think this would be
only a big problem, if you created an own template...
Maybe you are referring to database backups as
templates? In such case there's no problem - as far as you
generate the backup with an officially released Drake CMS
siedlerchr
Re: FANTASTIC!
10 September 2007 18:07
Anonymous
I think you missunderstood my post a bit...
I know
that there ist no Support for SVN, that is the point. I didn't
talked about the SVN revisions, I meant the official Drake
versions.
Quote:
We
are instead ALWAYS supporting the official releases' database
backups. This must be made clear once for all: there *is* full
backward compatibility, you can import a database from a previous
official Drake CMS release into a more recent one without loosing
your data.
I don't know if I understand
that, you just mean, when I'm importing my old databes from, e.g.
version .0.3 to version .0.4.5 and not the
other way round?
Quote:
If you are talking
about the Gladius DB database files you should be very careful:
it is not a good habit to copy over those files, unless you track
the Gladius DB version used by Drake CMS and copy them ONLY
between same Drake CMS versions.
The correct process
is to make a database backup and restore that one.
I wasn't talking about Gladius, I was writing about databases
in general. As far as I know there would be no problem to
migrate from Gladius DB to Mysql, so it would be easy to relocate
Drake to another server.
I have also a question: As far as I understood your post
Quote:
Here here here! Using a
BETA for a live website is not a good thing, not really by the
data integrity point of view but by the usability and general
user experience: BETAs use to have broken features...just because
we have not yet fixed them
it is better to make
backups than to copy all of drakes data to e.g another server.
Let me give you an example: I create a drake site
with a lot of content on my local Webserver (e.g XAMPP) and then
I decide to copy thsi site completly to my webspace on a
server.
When I understood you correctly, I should
first make a backup of the drake on my local server and then I
should install drake on the webspace on the internet and import
the db in the drake version, is that correct?
And what
do I do with the downloads, is it enough, when I just copy the
download folder or ist there anything else to take notice of?
Regards Christoph
legolas558
Re: FANTASTIC!
10 September 2007 19:35
Anonymous
Quote:
I think you
missunderstood my post a bit...
I know that there ist
no Support for SVN, that is the point. I didn't talked about the
SVN revisions, I meant the official Drake versions.
Oh, sorry, I am being pedantic these days
because some people might not have understood that. Quote:
Quote:
We are instead ALWAYS
supporting the official releases' database backups. This must be
made clear once for all: there *is* full backward compatibility,
you can import a database from a previous official Drake CMS
release into a more recent one without loosing your data.
I don't know if I understand that, you just
mean, when I'm importing my old databes from, e.g. version
.0.3 to version .0.4.5 and not the other
way round?
No, this will be possible with more
Stable releases. At some point we will consider the n.n.X
change in our version to be a really minor change - but for now
each release is always a big change.
Quote:
Quote:
If you are talking
about the Gladius DB database files you should be very careful:
it is not a good habit to copy over those files, unless you track
the Gladius DB version used by Drake CMS and copy them ONLY
between same Drake CMS versions.
The correct process
is to make a database backup and restore that one.
I wasn't talking about Gladius, I was writing about databases
in general. As far as I know there would be no problem to
migrate from Gladius DB to Mysql, so it would be easy to relocate
Drake to another server.
Ok.
Quote:
I have also a
question: As far as I understood your post
Quote:
Here here here! Using a
BETA for a live website is not a good thing, not really by the
data integrity point of view but by the usability and general
user experience: BETAs use to have broken features...just because
we have not yet fixed them
it is better to make
backups than to copy all of drakes data to e.g another server.
Let me give you an example: I create a drake site
with a lot of content on my local Webserver (e.g XAMPP) and then
I decide to copy thsi site completly to my webspace on a
server.
When I understood you correctly, I should
first make a backup of the drake on my local server and then I
should install drake on the webspace on the internet and import
the db in the drake version, is that correct?
If
the remote website's server is the same (and this probably never
happens), and if you are using a flatfile database, you could
copy all the files.
Otherwise..read below.
Quote:
And what do I
do with the downloads, is it enough, when I just copy the
download folder or ist there anything else to take notice of?
Regards Christoph
You
just have to copy your user files in the same location; Drake CMS
does not store the absolute path, so matching the relative path
will be enough. BUT...
You could instead create a
Tarball backup and restore that one; once you pack the tarball
backup you can remotely extract it using the veloce.php script.
siedlerchr
Re: FANTASTIC!
12 September 2007 19:46
Anonymous
Quote:
You could instead
create a Tarball backup and restore that one; once you pack the
tarball backup you can remotely extract it using the veloce.php
script.
So, the script is for unpacking .tar
files? Is it only for drake or could I use it for other
things=?
PS: Why coudn't I download a .php file with
the FF?
legolas558
Re: FANTASTIC!
12 September 2007 20:29
Anonymous
Quote:
Quote:
You could instead
create a Tarball backup and restore that one; once you pack the
tarball backup you can remotely extract it using the veloce.php
script.
So, the script is for unpacking .tar files?
Is it only for drake or could I use it for other things=?
It is for any .tar or .tar.gz file; I have written
it for everybody - open source! Quote:
PS: Why coudn't
I download a .php file with the FF?
It's
not because of the client browser, but because of the server:
.php is executed not served. Rename that file to .phps to
download it.
FANTASTIC! 
