[eluser]TheFuzzy0ne[/eluser]
1. I'd have to say it depends exactly how much text you have to store in the file. If you need to store paragraphs of text, then I'd recommend you break things down so you don't have a big-a$$ file being loaded each time your CMS runs. So essentially, you'd have several language files or more for each language. The only other alternative I can think of, is to store this information in your database, but I think that would make things too complicated, and you'd be screwed if you had a database error.
2. If you feel that you want that feature, then you don't really have much choice. If something is configurable, it has to be configured somewhere. I'd suggest forcing the user to use a specific table name. That way your installer can take care of everything, and your users can have their Web site up and running in minutes. How about you keep table names out of the config file, and let you're code store the defaults. If the user wants to change a table, they can add an override to the configuration file? Personally, I still think they should stick to the names you've chosen, and just let them choose a prefix to prevent clashes if they need to share a database.
3. If they are in separate files I can only assume that's for a reason. I'd suggest using a simple asset manager or something. I just created one myself. It's fairly simple. It loads any scripts/CSS common to all pages via the config file, and then I can add script/CSS files and meta data on the fly. I have a __toString() method which allows me to echo $this->assets in my HTML head, and Robert's ya father's brother!
4. I'm not sure I understand this problem. All of this wouldn't be done via the auth library, it would be done using another library wouldn't it?
