Initial Files!

Sounds cool Susan!

Awesome stuff. Are you integrating the original Eto DB tables in the install process?

How about an upgrade script from MODx2rc2?

The CVS doesn't seem to have the main site index.php file in it.

I've got a correct install from the latest files in CVS (rc3?) You can't log in, the files are all fskd, but the database is in good shape. Too much crap, in my opinion...too much room for errors to creep in. See my posts about getting the core straightened out before adding "sexy" goodies. I don't mind being troubleshooter, but the troubles are multiplying faster than I can shoot them.

It starts with the license page, goes right into newInstallStart, gets the info, goes to installNewDB, if it goes OK gives the option to go to installSnippets page or log in. InstallSnippets page just installs selected snippets, then gives link to log in. Login page comes up OK, but looks funny.

Once it all works correctly up to a working login, (whether the admin scripts themselves work or not!) I'll work on adding upgrading from RC2. Although I have questions about that...pretty soon we'll have upgrade scripts coming out of our ears if we keep it up. We should settle on an upgrade policy. From 0.6 to ModX to Rc2 to Rc3?

Enough for tonight. I'm beat; these allergies are killing me.

The new CVS module is now called "moxie" and I just committed a clean copy of the files that are running pixelhick.com successfully.

Go get 'em folks!

Hi Susan,

Yeah I like the $base_url and the $base_path config properties as well.

I would also like for you to save a site_id setting inside the database (in system_settings table) whenever a new installation takes place. This should be a unique id for each installation.

I would also like for you to save a site_id setting inside the database (in system_settings table) whenever a new installation takes place. This should be a unique id for each installation.

What will that be for?

Yeah I like the $base_url and the $base_path config properties as well.

Any reason these should not be part of the Etomite Configuration and stored in the DB appropriately?

What will that be for?

The site_id setting will be used when setting cookie values. This will also be useful in solving multiple modx installations on the same domain:

ww.mydomain.com/
ww.mydomain.com/community/ishop
ww.mydomain.com/community/overturn
ww.mydomain.com/community/partystore

Yeah I like the $base_url and the $base_path config properties as well.

Any reason these should not be part of the Etomite Configuration and stored in the DB appropriately?

Either way should be fine but I think it would be easier to modify the config.php file during a site move rather than to modify the database.

Either way should be fine but I think it would be easier to modify the config.php file during a site move rather than to modify the database.

Especially since I'd venture to say any move would require changing the config.php file anyway (and this isn't a value that should ever need to be changed from within the backend), I'd also think the config.php file makes sense.

Either way should be fine but I think it would be easier to modify the config.php file during a site move rather than to modify the database.

Especially since I'd venture to say any move would require changing the config.php file anyway (and this isn't a value that should ever need to be changed from within the backend), I'd also think the config.php file makes sense.

Fair enough, and I agree -- in fact, after further consideration, I actually prefer it in the config.inc.php after my experiences with WordPress, which does store them in the DB. WP requires me to export the site to a text file, do a global search replace on the absolute URL's used and then execute the modified script at the new location (or run similar queries on specific fields, though I preferred the other way since I could hit all the posts in addition to the config values).