Issue 18.0.72 broke IP Default Webites Ubuntu 24

[LRLD]

Server operating system version

Ubuntu 24.04.3

Plesk version and microupdate number

Plesk Obsidian 18.0.72 Web Pro Edition

Hi,

Just installed 18.0.72 and two things, please remove the "custom template warning" unless you have actually changed the templates!!
Secondly, now the site assigned to be the default for the IP shows the Plesk default page!
Now what has changed?? All my SNI sites are fine!

I've tried removing the previous fixssl.conf to test but no, still the Plesk default on the default site for the IP!

This is affecting both of my servers! even with new custom templates.

TIA

 

[LRLD]

So I just changed the default site for the IP to none and the site works, so whatever has changed in this update has broken the IP_Address > default site!

 

[nmdpa3]

Same situation, thanks for the update on the fix. Another Plesk update fail! That is two in a row now that caused serious issues. Testing needs to be much better before these updates are released.

 

[learning_curve]

Just installed 18.0.72 and two things, please remove the "custom template warning" unless you have actually changed the templates!!
Secondly, now the site assigned to be the default for the IP shows the Plesk default page!
Now what has changed?? All my SNI sites are fine!
I've tried removing the previous fixssl.conf to test but no, still the Plesk default on the default site for the IP!
This is affecting both of my servers! even with new custom templates.

FWIW In our case(s), we have had none of the above, post the upgrades to 18.0.72. No issues at all in fact.
Caveat: We don't use any Custom Templates (in the same way you may be doing...) and we don't (currently) have any laravel driven applications
I've added a link to this, in the other similar thread that's been posted.

 

[Sebahat.hadzhi]

The behavior was identified as a bug with ID PPPM-15085. The fix will be introduced at one of the upcoming releases. In the meantime, the only workaround is setting Default Site to none in Tools & Settings > IP Addresses as already suggested by @LRLD .

 

[trialotto]

@Sebahat.hadzhi

The statement or request

please remove the "custom template warning" unless you have actually changed the templates!!

is a "thingy" that should be addressed sooner or later.

I do not know to which type of custom templates @LRLD is actually referring, but Plesk is (on the one hand) allowing custom templates (for instance, for Nginx) and (on the other hand) failing miserably whenever a standard operation has to be executed in the presence of custom templates.

It should really not be the case that custom templates prohibit Plesk to execute operations, certainly not if the custom templates do not affect the operations.

Could Plesk Team have a good look at this particular issue?

Kind regards....

 

[Sebahat.hadzhi]

@trialotto , thank you for your input. However, the bug PPPM-15085 in this particular discussion is not related to custom templates. Regarding @LRLD 's mention of the warning I will be happy to bring that to our team's attention as long as I have a way of replicating the error. If you are experiencing a specific issue with custom templates kindly open a new thread and provide us with clear details on the issue. Thank you in advance.

 

[Lrnt]

Same issue (All websites down after Plesk update) and same fix for Debian 12.
@LRLD you saved my day! Thank you !

 

[LRLD]

Fixed the issue where, after adding specific WordPress plugins to a WordPress website, browsing the website resulted in an infinite redirect loop if that website was set as the default website for an IP address in Plesk. (PPPM-15085)

No, that hasn't fixed it, now I get "too many redirects" when I set the default website for the IP.
One server doesn't even have Wordpress on the default IP.

 

[TorbHo]

@Sebahat.hadzhi I hope that the current update 18.0.72 will be quickly withdrawn due to the issue and is no longer being distributed until the problem has been fixed?

 

[Sebahat.hadzhi]

@TorbHo , there was an update released today, Plesk Obsidian 18.0.72 Update 1 that addresses the issue. The wording is a bit specific to how the issue was initially reported, but the root cause is the same:

Fixed the issue where, after adding specific WordPress plugins to a WordPress website, browsing the website resulted in an infinite redirect loop if that website was set as the default website for an IP address in Plesk. (PPPM-15085)

 

[LRLD]

@TorbHo , there was an update released today, Plesk Obsidian 18.0.72 Update 1 that addresses the issue. The wording is a bit specific to how the issue was initially reported, but the root cause is the same:

Hi @Sebahat.hadzhi,

I applied the update, and tried to assign my site as the default but now I get "too many redirects" on the site instead of the Plesk default web page, so I have reverted back to "none" again.

TIA

 

[Sebahat.hadzhi]

@LRLD , thank you for the update and the details. Could you please also confirm if you are assigning a wildcard domain or it is a standard one?

 

[learning_curve]

@Sebahat.hadzhi I hope that the current update 18.0.72 will be quickly withdrawn due to the issue and is no longer being distributed until the problem has been fixed?

That's an over dramatic response
Post #4 - It doesn't affect all users...

 

[TorbHo]

That's an over dramatic response
Post #4 - It doesn't affect all users...

It actually does affect a large number of users. Why should an update only be stopped if every single user is impacted? Even if it doesn’t break things for all, the fact that it disrupts many is reason enough to reconsider or pause it.

That said, it seems the issue has been resolved with the current update, so it’s no longer critical right now. Still, it’s worth keeping in mind for future releases, since lately Plesk updates have been causing problems more frequently.

 

[trialotto]

@TorbHo

This statement

That said, it seems the issue has been resolved with the current update, so it’s no longer critical right now. Still, it’s worth keeping in mind for future releases, since lately Plesk updates have been causing problems more frequently.

is absolutely true, but it is not something of "lately".

In fact, this is a natural tendency for years now : Plesk evolving with many (many) hickups that require bug fixes that require patches.


To some extent, this "tendency" is the result of the desire or even the need to support all kinds of packages and OSes.

For the average Plesk user or admin, it is barely imaginable how the above affects (the complexity) of Plesk development and development planning.


That being said, there is a trade-off to be made, which trade-off Plesk has made only partially.

On the one hand, parts of the Plesk environment are "outsourced" in the sense that extensions replace core packages - this is actually good, if and only if those extensions are actually any good (and that is not always the case).

On the other hand, the core packages of Plesk are becoming more complex (for the sake of augmented functionality) and more divers (for the sake of support of multiple OSes) - this is also good, if and only if development planning is good.


In general, I can only conclude that bug fixes (and/or patches) have been necessary more frequently, but also that they are available more fast.

As a result, it is my personal opinion that it is quite good - on average.

Nevertheless, a bit of development planning should allow the prevention of patches of bug fixes that were not proper.

Stated differently, I agree with you that more effort should be taken to preven that the patch-on-patch situation occurs continuously.

After all, a bug fix should be a once-and-for-always solution.


Kind regards.....


PS Plesk is really improving with respect to this matter, so we should also give Plesk the credits they deserve and the feedback they need to improve.

 

[TorbHo]

The only solution I see for this actual problem with updates is to let users decide for themselves whether they want to install an update immediately upon release, or (as in the past) to have the option of installing only those updates that have been tested for a longer period and are considered stable for productive use.

This feature already existed in earlier versions of Plesk and, after its removal, has been requested back multiple times by the community.

We have been using Plesk on various servers for many years, so I am very familiar with the older versions and have followed its development closely. Plesk is still a good piece of software, but unfortunately the overall trend is moving in a negative direction. Instead of listening to users, important and requested features are either completely ignored for many years or are suddenly offered only as extra paid extensions.

Please, Plesk, listen to your community. Many users I know have already switched to alternatives. At this rate, you will end up losing even your most loyal customers.

 

[learning_curve]

The only solution I see for this actual problem with updates is to let users decide for themselves whether they want to install an update immediately upon release, or (as in the past) to have the option of installing only those updates that have been tested for a longer period and are considered stable for productive use ~~~

This ability, might possibly depend on your hosting partner / your licensing agreement or some other variable (or maybe not), but AFAWK the ability to simply avoid any / all Plesk auto-updates and only apply Plesk updates manually, is still fully functional. It can be selected here: https: *.* :8443/admin/pum/settings

You have the same choice with Plesk Extensions too: https:// *.* :8443/modules/catalog/index.php/updates

We haven't used auto-updates for well over three years now, for the very reasons that you've mentioned.
Pretty sure that this was the same rational behind Plesk allowing these choices in the first place.

 

[TorbHo]

@learning_curve
Thanks for your reply, but I think you might have misunderstood me. I am not talking about disabling auto-updates and doing everything manually – I am aware that this option still exists.

What I mean is the old functionality Plesk used to have: the ability to choose between installing updates immediately after release or only after they had been tested for a longer period and classified as stable for production use.

That feature is no longer available. Today we only have the choice between auto-updates or fully manual updates, but not the option to automatically receive only the “delayed / stable” updates as in earlier Plesk versions.

 

[learning_curve]

@learning_curve
Thanks for your reply, but I think you might have misunderstood me.

No, did understand, but should have added more detail.

I am not talking about disabling auto-updates and doing everything manually – I am aware that this option still exists. What I mean is the old functionality Plesk used to have: the ability to choose between installing updates immediately after release or only after they had been tested for a longer period and classified as stable for production use.

Correct, that level of finesse / granular level of updates was removed some time ago. Essentially, that was Plesk saving work on releasing different product (versions) & schedules as you already know. However, you can still achieve a 'form' of this (although in a far more blunt way... & without with the same depth of level control) by only using manual update's. Yes, this is just a delay option really, as opposed to your preferred, but no-longer available choice. To add recovery to this, there's nothing to stop you taking a complete server snapshot back-up, applying the latest Plesk update(s) manually, promptly testing that new release and reverting back to the snapshot back-up - IF - the latest Plesk update does cause issues on your server. Not perfect version control, but it works

Alternatively, if you really do need to, you could almost achieve the same selective level of Plesk updates, by making ALL updates (not just Plesk updates) manually via CLI only. That's via ssh and not via the Plesk ssh-terminal extension. That's a lot more work than the previous option that was available from Plesk of course (and very accurate record detailing would be needed, as well as robust server admin experience and skills), so, it depends on your own priorities.

We don't have the same needs as you, but for different reasons, we do run all updates manually via CLI anyway (after taking shapshot back-ups in advance).