Thread

Anything that will allow URL rewriting will work.  You don’t need htaccess if your server can/does support another method.  We generally recommend it as its a proven, well supported avenue, but not everyone uses it.

EE currently only officially runs on MySQL.  Our PHP framework (CodeIgniter) supports many, many databases, and I think its a reasonable assumption that we’re moving in that direction, but currently its only MySQL.  There’s no timetable for another database right now unfortunately.

Welcome to EE!

Thanks Nevin, but the methods listed there (such as including htaccess into the template!) sound from kludgish to downright scary.

I think you misread something in the URLs I provided you are not placing a .htaccess file in a template, one of the methods can create a .htaccess file based on the layout of your EE setup, but you are only doing that if major changes to the layout of your site.  There are multiple methods outlined in the links I provided.  I personally only rename the index.php file, and it has worked well in our case for SEO uses.

We can only have Rewrite and other directives in our httpd.conf, no .htaccess files and such allowed for security/performance reasons. Is there a httpd.conf way to get rid of the ugly index.php bit in the URLs?

Unless you go overboard with a .htaccess file we have sites powering millions of unique visitors, and 10’s of millions of EE powered page views even with rather complex .htaccess files.

I am not sure of the direction of this question, but can recommend some good apache configuration books that cover this better.  But you do realize that a .htaccess file is only a extension of the apache httpd.conf setting/configuration.  Anything you can do in .htaccess can always be done directly in a httpd.conf file, the other way is not the case depending on what you specifically allow to be done in .htaccess with the use of Options and AllowOverride functions in httpd.conf.

Q#7. Will EE work with PostgreSQL? I’d rather not bother with MySQL on our live servers if we can do without it.

I think the EE developers can answer this in more detail for you but the answer is technically no, that is why MySQL is listed as a requirement for EE.  Technically I believe you could change specific EE files to use SQL queries to any SQL database, but of course you would not get official support for anything of that nature.  I believe the dev group has specified they are looking at addressing this in the future.  I would assume because you stated you need to output content as static pages that the database used in the production environment would be of little concern as you would not be pushing production level traffic through MySQL and a basic MySQL configuration should be more than fast enough and secure for intranet/authoring functionality, though again if you need Postgres EE is not really going to fill the role you need in a number of ways.  It is designed to be used in a fully dynamic publishing environment, and it is based, at least currently, on the use of php and MySQL.

Please keep in mind I do not represent the software development group, so they may have some specifics for you on EE and use/future use with other databases and the like.

I would assume because you stated you need to output content as static pages that the database used in the production environment would be of little concern as you would not be pushing production level traffic through MySQL and a basic MySQL configuration should be more than fast enough and secure for intranet/authoring functionality, though again if you need Postgres EE is not really going to fill the role you need in a number of ways.  It is designed to be used in a fully dynamic publishing environment, and it is based, at least currently, on the use of php and MySQL.

Thanks for your patient response. Yes, if we could produce static pages then the underlying DB would be of little concern, but from I read in this thread and others, EE does not produce static pages at all and relies instead on caching of different flavors. Caching is great and we have tried it ourselves, but it is not the same as a truly static page in the face of, say, a Digg storm.

Apart from the obvious benefits of being able to write complex SQL queries without worrying about non-standard kludges, Postgres has proven (for us) to be significantly more reliable over monstrous traffic. It allows much better tweaking of kernel level system parameters; rocket science compared to MySQL’s puerile query cache and such. Most importantly, pgsql never leads to data corruption, which is more than can be said for our experience with MySQL beyond 3 million rows in a highly concurrent table.

Anyway, I earnestly hope the dev team will consider putting SQLs in one place or in some specific functions so they can be adjusted and optimized for other databases.