31,003
edits
Setup Other: Difference between revisions
Jump to navigation
Jump to search
m
→For SaaS / Cloud hosting integrators
Tag: 2017 source edit |
Tag: 2017 source edit |
||
| Line 1,160: | Line 1,160: | ||
*'''MAILING_LIMIT_SENDBYDAY''' ► This is a limit of number of emails, an instance can send. Note that this is not a hard limit; it is just the quantity that will be displayed on warnings on screen. For a real limit, this must be implemented into the system. | *'''MAILING_LIMIT_SENDBYDAY''' ► This is a limit of number of emails, an instance can send. Note that this is not a hard limit; it is just the quantity that will be displayed on warnings on screen. For a real limit, this must be implemented into the system. | ||
*'''MAILING_LIMIT_WARNING_PHPMAIL''' ► Set this value to a translation key. Then add translation keys into the instance so user will see a message when into the email setup page. For example, you can set a message to say ''Warning: To avoid abuse, when using default setup, you are restricted to 500 emails per day for all your application (account may be suspended in case of violation of this rule. You can setup application to use your own SMTP server for sending email so you want have no restriction at all (see menu Home-Setup-Emails)'' | *'''MAILING_LIMIT_WARNING_PHPMAIL''' ► Set this value to a translation key. Then add translation keys into the instance so user will see a message when into the email setup page. For example, you can set a message to say: ''Warning: To avoid abuse, when using default setup, you are restricted to 500 emails per day for all your application (account may be suspended in case of violation of this rule. You can setup application to use your own SMTP server for sending email so you want have no restriction at all (see menu Home-Setup-Emails)'' | ||
*'''MAIN_ALWAYS_CREATE_LOCK_AFTER_LAST_UPGRADE''' ► If set, when you launch upgrades of your customer instances, you are sure that the upgrade process recreate automatically the file install.lock and remove the upgrade.unlock so the administration tools like install.php, upgrade.php and repair.php can't be used on your customer instance (until the install.lock file is deleted or the upgrade.unlock file is created). | *'''MAIN_ALWAYS_CREATE_LOCK_AFTER_LAST_UPGRADE''' ► If set, when you launch upgrades of your customer instances, you are sure that the upgrade process recreate automatically the file install.lock and remove the upgrade.unlock so the administration tools like install.php, upgrade.php and repair.php can't be used on your customer instance (until the install.lock file is deleted or the upgrade.unlock file is created). | ||