Nuxwin you don't understand him. He tried to rewrite the Script for i-MSCP, but it's not possible.He never said he tryed it with i-MSCP
First time, I've not understood, it's true but read my last post correctly... Users must not use the tools from ispCP are not compatible with i-MSCP. Now, if Daniel or any other developer want develop such tool for i-MSCP, i'm not against that idea...
Hello ;
Well, don't search more. The script from ispcp project is not compatible with our panel. I don't understand why you tried that...
Display More
1. DNS settings like (for admin):
a. creating DNS templates
b. editing DNS templates
c. Mass DNS template rebuild (in cases when ns1 and ns2 IP change). Here we can have all domains listed with ability to select ones that we want nameservers to be changed. Then we select their "new default" template and hit rebuild.
1-1, DNS for client:
a. ability to add/change/preview DNS records for their domain if allowed. for ex. adding a record for subdomain. I know there is a feature, but it seems I can't edit it. Or I'm dumb to see it.
All DNS interface will be rewritten after next stable. We'll care about your sentence.
2. roundcube/horde support. Roundcube had to dealt with caution, since during update it replaces old roundcube database with default one wich results in Contact's loss.
It's already planned to replace squirrel with roundcube. Don't worry about data, we will manage in good way.
3. high quality web-FTP client like extplorer
Already planned too.
4. No possibility to create customer through admin account (which is not big problem so far but it rise some confusion).
It's the expected behavior: admin manage the resellers and the resellers manage their customers. Admin still able to switch to the reseller interface in few click and so, it's not a problem.
5. Not sure, but It seems that all domains share same php.ini file settings. I think its good idea that every customer has it's own php.ini file cotroled by admin. In that case when you change something, or some setting, it affects only that domain.
For now, when you are using FCGI, each customers can have either a global php.ini for all of its domain entities or a php.ini for each of its domain entities.
Stilll that if you are using ITK, it's not possible to load many php.ini.
Whatever the customer can change some PHP directive values from its UI level.
6. Customer disable
It's already partially implemented.
Cheer ;
The directory structure is modified from ispcp to i-mscp. Also you are not using full paths on require so this throws lots of file not found in the migration script.
Normally, that should not pose any problem since the new GUI directory is copied before the setup/update process.
Also, some functions don't seem to exist anymore.
Really 
, what are the missing functions exactly ? Well, I'll try a migration from ispcp 1.0.7 to last master to see. Feel free to send us any log. Whatever, I'm curious to know the exact procedure you followed to migrate.
Cya
Just for your understanding
0 for alpha (status)
1 for beta (status)
2 for release candidate
3 for (final) release
For instance:
First stable release
1.0.0.0 First ALPHA release
1.0.0.1 Second ALPHA release
...
1.0.1.0 First BETA release
1.0.1.1 Second BETA release
...
1.0.2.0 First RC release
1.0.2.0 Second RC release
...
1.0.3.0 First stable
1.0.3.1 First stable (bugfixes)
1.0.3.2 First stable (bugfixes)
...
Second stable release
1.1.0.0 First ALPHA release
1.1.0.1 Second ALPHA release
...
1.1.1.0 First BETA release
1.1.1.1 Second BETA release
...
1.1.2.0 First RC release
1.1.2.0 Second RC release
...
1.1.3.0 Second stable release
1.1.3.1 Second stable release (bugfixes)
1.1.3.2 Second stable release (bugfixes)
...
Third stable release
1.2.0.0 First ALPHA release
1.2.0.1 Second ALPHA release
...
1.2.1.0 First BETA release
1.2.1.1 Second BETA release
...
1.2.2.0 First RC release
1.2.2.0 Second RC release
...
1.2.3.0 Third stable release
1.2.3.1 Third stable release (bugfixes)
1.2.3.2 Third stable release (bugfixes)
...
Can you develop little? I'm curious when I read your sentence.
It's also my opinion Sasha. For the first proposition, that means that we must provide a restricted API to avoid the reseller to do all they want with core code. I'll provide such restricted API via a plugin later.
Hello;
No, it's a special script that handle REST requests such as
With URL rewriting
So here the web service is BoxBilling (plugin BoxBilling that provide Web service controller) and the method called by external application is suspendAccount() with 1 passed as argument.
It's only a little not working example.
Hello community ;
Introduction
In next release, I'll introduce a REST server that will allow any developer/contributor to provide plugins that act as web service controller. That will allow communication between i-MSCP and external applications such as BoxBilling, WHMCS but also any cms and so on... The REST server alone will do nothing but if someone develop a plugin that provides such Web service, he will be able to use the REST server to handle the incoming requests.
Usage example
For instance, many resellers have their own sites for Web Hosting, and sometime, some of them want add a little form on their site to allow the new customers to subscribe a hosting plan or allow direct registration without reseller confirmation. For now, it's only possible to subscribe a hosting plan via the i-MSCP order panel interface.
With the REST server, the reseller will be able to code a plugin for i-MSCP that will be able to talk with its site and process the user subscription (order) or direct registration without confirmation.
To resume (in few lines)
For the i-MSCP side, the reseller will have to create a little plugin that listens on the onRestRequest event and that do the needed tasks for the specified request.
On the reseller site, the reseller will have to create a little script that implements a REST client. This client will be responsible to query the i-MSCP Web service (provided by the plugin) via the i-MSCP REST server.
Of course, I also provides the REST client ready to use that the reseller will be able to reuse for its own application.
Question
Should we allow the reseller to add its own plugins (with admin's confirmation for activation) and only run them only for him (by checking a kind of token in the incoming request) or should we force the reseller to ask the admin to add its plugins and activate them?
Since your are the users of i-MSCP, I let you give us your opinion.
Hello packagers ;
Just to mention that English packages are greatly appreciated. In my opinion, we must have a least an English version for all of them (international language). Whatever, I thanks you for your great job.
