Having still used Typo3 in version 6.2.12 I was offered two update options, one on the main page to 7.5.x and one on the application page to 6.2.18.
Through a night of backups and restores because I got stuck in the update to 7.5.x,

I lost the option to update to 7.5.x. It's not offered anymore.

I tried another restore with deleting the content of HTTPDOCS completely, it did not help. The app's name on the application management page is now "Typo3 7.6.15" which was shortly true, but is not anymore after several restores.

What I need now is a button I can click for Plesk to re-check the application version and all available updates, best with a list of all updates which are possible, not just the most recent version one.

I need that update. My last hope now is that the update automagically re-appears with the next Plesk update, otherwise I am stuck for ever, because Plesk seems to think I already did update.

Currently domain logs look like

541004 -rw-r--r-- 2 root root 0 Mar 2 15:01 access_log
562544 -rw-r--r-- 2 root root 0 Mar 2 15:01 access_log.processed
538890 -rw-r--r-- 2 root root 827 Mar 2 15:01 access_log.processed.1.gz
538922 -rw-r--r-- 2 root root 642 Mar 2 14:59 access_log.processed.2.gz
538925 -rw-r--r-- 2 root root 907 Mar 2 14:59 access_log.processed.3.gz
538908 -rw-r--r-- 2 root root 582 Mar 2 14:58 access_log.processed.4.gz
538915 -rw-r--r-- 2 root root 787 Mar 2 14:57 access_log.processed.5.gz

If user sets dateext in logrotate config they look more user firendly
-rw-r--r-- 2 root root 8985 Mar 2 13:25 access_log
-rw-r--r-- 2 root root 26020 Mar 2 13:21 access_log.processed
-rw-r--r-- 1 root root 20 Feb 12 03:50 access_log.processed-20170213.gz
-rw-r--r-- 1 root root 20 Feb 13 03:16 access_log.processed-20170214.gz
-rw-r--r-- 1 root root 20 Feb 14 03:23 access_log.processed-20170215.gz
-rw-r--r-- 1 root root 20 Feb 15 03:39 access_log.processed-20170216.gz

However Plesk would not rotate such logs correctly (old logs are not being deleted from vhost/domain.tld/logs directory.

Currently when a website is created Plesk copies the default website files to the document root for that website.

This has two issues in my opinion: 1 the user has to delete those files to start (not a big issue but would be nice if they didn't have to go through that step), and 2 when they delete those files they then get the default Apache2 Test Page, which at this point defeats the point of having default website files copied.

I believe a better solution would be to change the No Index Apache location to a location that Plesk manages e.g. where it currently stores the default website files.

This would make things seem a little cleaner and just a little more straightforward for new users setting up their first website.

Thank you
Aaron

Hello,

currently any change done to subscriptions using customize will result in causing the subscription to lock and need resyncing. The only two buttons to save customizations are "apply and lock" and "update and lock".

The change you make might affect just one area like the renewal date however the whole subscription is marked as locked. If you unlock and sync all customizations made through other areas of the subscription are removed, including custom php directives, php memory_limit, and other configuration settings that are important to keep so that the customer's subscription will keep their websites working.

As it currently stands, after first modification of the renewal date for example we end up having all subscriptions locked and unsynced therefore we can't automate bulk changes in subscription plans like increasing HDD space, or mailbox limits.

If we manually resync the subscriptions, we lose all customizations that are mission critical for the customers. So we either have to work through every subscription one by one adjusting or we have to work through every subscription and notice all specific directives that are important to the customer and then reimplement them after sync.

That's tedious,time consuming and prone to errors.

Simple example,
1. create a service plan using 256MB as memory_limit for php and assign it to a subscription
2. go to the subscription -> domain panel
3. click on php settings icon
4. add a php directive like memory_limit = 1G and save
4a. Go to subscription and click on customize
1. Change renewal date
2. Hit update and lock
3. Hit unlock and sync
The result is the directive memory_limit =1G is lost.
4b. Go to service plan and adjust mailboxes from e.g. 5 to 6
1. Sync plan with subscriptions
Result is the directive is lost.

This effectively kills any versatility in the service plans for mass changes and is potentially dangerous for the customers as it can cause things to break.

In my opinion at the very least each service plan tab as we define it

Resource
Permissions
Hosting Parameters
PHP Settings
Applications

should have a separate lock. That way when we change something in the PHP settings tab, only the php settings are marked as to need resyncing. When we change something in the resources, only resources will resync etc etc.

This would still be prone to errors when editing php settings of course but at least not when you're adjusting resources.
Ideally a list of all changes to each subscription if you decide to sync again should appear too and ask for confirmation. That way at least you can note what to fix after plesk breaks it.