Question What columns do you want to see in the domain list?

[Peter Debik]

Server operating system version

All

Plesk version and microupdate number

All

A few weeks back, the Plesk team ran a survey about the essential columns needed in the domain list. The results highlighted a few columns that many of you are missing:

1. PHP version
2. SSL status
3. Web Server (Apache / Nginx)

Yet, there's a limit on the number of columns we can include while ensuring the table fits within the screen width. To find the best solution, we need to dig deeper. We're on the lookout for people who are really interested in having these columns included.
If you're keen on adding these columns, we'd love to hear from you:

1. How do PHP, SSL, or Web Server settings impact your domain tasks?
2. How often do you encounter these tasks?
3. How are you currently managing these tasks without these columns?
4. What changes to your workflow do you anticipate once the columns are available?

Feel free to share your thoughts in the comments below this post. Thanks so much in advance!

 

[Kaspar]

I can't exactly remember what options where available to chose from in the Plesk survey, but I remember that all of them seemed useful. It was very hard to pick options that where essential for me. Because that's not as static as you might think. For example when switching sites over from one PHP version to another it would be very useful to have a column with the used PHP version in the domain list. Switching sites takes a certain amount time (depending on the number of sites and complexity of the sites). When the PHP version switch is finished for all sites it becomes less relevant to have the PHP version as column in the domain list. But it becomes relevant again when a new PHP version gets released, because then (at some point) I'll have to switch over the PHP version for each site again.

What I am trying to say is that which columns can be considered essential to a user is actually fluid. Sometimes one thing is essential, sometimes another thing is essential to have. Besides, what is essential to one user might not as essential to another user. Of course there is limited (display) space and not every column can be displayed all at once. But why not let users choose from a list which (two or three) columns they want to display?

 

[Kaspar]

Also, @LocalOTA I am tagging you as you mentioned in a previous thread that the "Hosting" location is essential for you to be sown in the domain list. I thought that you might want to share your feedback/option on this matter as well.

 

[Stas Yuriev]

Kaspar, thanks for the comment.
I am a product designer at Plesk. I'm currently working on the domain list improvements and I asked Peter to help me with this research.

I fully agree with you, that all the columns are not needed all the time, and their number might vary depending on the user and the use case. Of course, providing customization for the columns is one of the options. But from our past experience, often when you invest in customization possibilities, you see that the overwhelming majority of users stick to the default configuration or configure the product in one and the same way. That's why before delivering any customization tools we always ask ourselves if we can deliver the optimal configuration out of the box instead.

As for adding any column to the table, we are trying to figure out first, what is the customer issue behind this request and if adding the column actually is the best solution.

From your post, I've learned that the PHP version column is useful when you need to switch your websites to the new version of PHP.
Could you please elaborate on how you currently switch them without having this column? And how will you change your workflow if you get it?

 

[Kaspar]

Hi Stas, thank you for reaching out. I always happy to provide more information.

[...] I fully agree with you, that all the columns are not needed all the time, and their number might vary depending on the user and the use case. Of course, providing customization for the columns is one of the options. But from our past experience, often when you invest in customization possibilities, you see that the overwhelming majority of users stick to the default configuration or configure the product in one and the same way. That's why before delivering any customization tools we always ask ourselves if we can deliver the optimal configuration out of the box instead.

As for adding any column to the table, we are trying to figure out first, what is the customer issue behind this request and if adding the column actually is the best solution. [...]

Understood, I guess the 80-20 rule applies here too. 80% of the users only use 20% of the features

I just used the PHP version as an example for my argument that what can be considered essential to a user is fluid. For me Diskspace usage and Hosting location (the document root path) are actually more essential. Because that's information I use on a regulair basis (weekly, sometimes daily). Having the PHP version shown in a column is very useful too, but not essential to me. (Neither are Web Server or SSL status for that matter).

Currently if I do have to switch the PHP version for a lot sites I go to Domains (using the Service Provider view), open the search filter and select the PHP handler from the dropdown box to list all sites that run a particular PHP handler.

Hope this helps a bit. Don't hesitate to let me know if have any additional questions.

 

[Stas Yuriev]

Kaspar, thank you for such a detailed answer! I would like to clarify a couple of things.

What do you do, after you filter out the old-version domains? Do you switch them individually or is it a kind of mass operation?

And since you mentioned filtering in the domains list, could you please share some feedback about working with the domain filter? Did you happen to face any issues or inconveniences when using it? When switching the PHP version or in any other case.

 

[Kaspar]

What do you do, after you filter out the old-version domains? Do you switch them individually or is it a kind of mass operation?

A bit of both. I switch PHP versions manually and do this in a mass operation as well. Last year for example I switched over 250+ sites from php 7.4 to PHP 8.0. For this I changed the PHP version from 7.4 to 8.0 in the Service Plans. Then I analyzed the logs files to see which sites caused any new errors. After which I manually switched back the PHP version for the sites that had errors. Later I used the domain list again to see which domains where still using PHP 7.4 and worked with the domain owners to make their sites compatible for PHP 8 and switched those sites over manually once they where compatible.

I did the same thing for switching sites from PHP 8.0 to 8.1. But that went a lot quicker because there where a lot less errors.

And since you mentioned filtering in the domains list, could you please share some feedback about working with the domain filter? Did you happen to face any issues or inconveniences when using it? When switching the PHP version or in any other case.

Sure. I like the domain list filter, it is useful to have. I don't use it daily, but perhaps a few times a month. Mostly for filtering on domain names, hosting type or subscribers. It would be nice if there where more options to filter from. For example to filter on web server (Apache / Nginx), mail service (enable or not), or if a domain uses a specific toolkit (WordPress, Laravel or Joomla toolkit for example).

There aren't any real inconveniences I can think of. Although one thing that feels a bit quirky is that filter value(s) persist when you click away and come back. For example when you filter on the value .com (to only list all the .com domains), then click away in Plesk to another page (for example to the Tool & Settings page). Then when go to the Domain list again, the filter is still active, showing only the .com domain. I sometimes forget that I previously used the filter and for a second I think "where did all the other domains go?". I am not saying this is a bad thing, I understand why this happens and it might even be useful too. I guess I instinctively expect that the filter gets reset when you click away.