Mountpoints will be removed from i-MSCP

So i understand correctly: Mount points will be still possible for subdomains and aliasses, you can offer another content on them ? The only change is, that you can't define them yourself?

no problem for me - a symlink will do the rest, but if you're going to delete the option to make an second webspace for aliasses and subdomains i will stand on the rc forever

please remember users that are using symlinks for patching: what will happen, when you use a "standard hosting" on a subdomain, but htdocs inside it is symlinked to another directory?

Quote from Webdesign Höhne

So i understand correctly: Mount points will be still possible for subdomains and aliasses, you can offer another content on them ? The only change is, that you can't define them yourself?

no problem for me - a symlink will do the rest, but if you're going to delete the option to make an second webspace for aliasses and subdomains i will stand on the rc forever

please remember users that are using symlinks for patching: what will happen, when you use a "standard hosting" on a subdomain, but htdocs inside it is symlinked to another directory?

Hello ;

1. Yes, all mount points will be defined statically and the user will not longer be able to fix it manually.

2. Why you want use symlinks ? HTTP redirection can do the work. Give me a concrete example of usage with symlink please.

3. The update path will work for i-MSCP installations without any exotics changes. You will have to undo your exotics changes to be able to update.

Quote from Nuxwin

2. Why you want use symlinks ? HTTP redirection can do the work. Give me a concrete example of usage with symlink please.

3. The update path will work for i-MSCP installations without any exotics changes. You will have to undo your exotics changes to be able to update.

1: Perfect

2: Multilanguage is the problem, my application is built by myself, it's available in english and german. the entire programming is nearly the same, it uses the same database in many ways. the translation is handled by files and inside the tables via suffixes. The script simply checks php varibles to determine which domain is active resulting in an output in your language.
-> domain1.de -> german content
-> domain2.us -> english content
problem with that case: replicating the content will be very load-intensive, we're talking about 800k temp files per week created for caching. if you're replicating the content cronjobs, caching, image uploads and other file based changes have to been run twice....
i also know some applications that aren't unpopular and are using the analogical mechanics (eg. shopware or other multi-client releated content management systems). These applications mostly use the domain as identifier, not an folder

3: no problem, thanks for the information, but i wouldn't call these changes exotic. It's very popular for plesk installations too when users are using one cms on multiple domains.