PHP 8.1.13

E

Erulezz

Verified User
Joined
Sep 14, 2015
Messages
703
Location
🇳🇱
24 Nov 2022

PHP 8.1.13 Released!​

The PHP development team announces the immediate availability of PHP 8.1.13. This is a bug fix release.
All PHP 8.1 users are encouraged to upgrade to this version.
For source downloads of PHP 8.1.13 please visit our downloads page, Windows source and binaries can be found on windows.php.net/download/. The list of changes is recorded in the ChangeLog.


PHP 8.0.x has entered security fixes only.

@fln now that versions.txt is linked to a new DA version, will this be out next month or can this be added in the next hotfix?
 
Unless we compile it ourselves, we can't upgrade to (yet) as CB is a part of DA now....... Which is utter bull-bull........

How does this new scenario even make sense?! Need to wait for "hotfixes" just to upgrade an important component to a server.... Bugs are bad enough with DA, now we have to wait to even have the latest versions of software!
 
Peter Laws said:
How does this new scenario even make sense?!
Click to expand...
I agree with this, makes no sense how DA is bundling these updates. MariaDB 10.6.11 was released back on November 7th - almost three weeks ago now. It's in DA version 1.645, which was released about four days ago. Looking at what's happening with that release I am in no rush to upgrade DA - which means I have to wait even longer for the database update. This new process is definitely a step backwards.
 
Peter Laws said:
Unless we compile it ourselves, we can't upgrade to (yet) as CB is a part of DA now....... Which is utter bull-bull........

How does this new scenario even make sense?! Need to wait for "hotfixes" just to upgrade an important component to a server.... Bugs are bad enough with DA, now we have to wait to even have the latest versions of software!
Click to expand...
100% agree.
they should make the CB version updates update seperatly again.

I remember updates being only a few days after upstream releases, not weeks
 
I didn't find bundling CustomBuild with DirectAdmin very useful at first, but I understand it now. CustomBuild and DirectAdmin are so intertwined that it is convenient to do so. This way it can also be tested more. I also think the new CustomBuild plugin is an improvement, although I don't use it much.

For example, a few months ago there was that bug where some CB scripts / revisions could no longer be updated. And now a single mirror/download server is also much more convenient. That way you also avoid all those questions lately where mirrors are no longer updated or that the sync frequency was only 1x per day and versions.txt was not in sync.

The only thing I would indeed like to see again is that versions.txt can be updated independently and does not require a new DirectAdmin build. That PHP 7.4 security fix was released a few weeks ago, but only available since this new DirectAdmin version.

But luckily we can always use custom_versions.txt (Hopefully this functionality will not go away:ROFLMAO:), which I always use for Composer, for example.
 
This never made sense to me. It never made sense to me when the other control panel was doing the same. The other control panel eventually changed to making updates separate. DirectAdmin always had them separate until they decided to merge them together and that decision could very well be it's undoing if you ask me.

You have to look at servers in terms of a stack. A control panel is just one piece of the puzzle. It's not THE piece of the puzzle.

In terms of what we've come to know in terms of a shared web hosting server, there's basically three main parts:

A web server - Apache, nginx, Litespeed, etc.
An MTA - Exim, Postfix
An IMAP/POP3 service - Dovecot, Courier (?)

Most everything in terms of shared web hosting revolves around these 3 main parts. Certainly PHP is the most popular programming language of choice for most users of the web server. You can argue that PHP fits in there some where, but I'd argue that it fits under the web server.

All that a control panel does is provide an interface for controlling these parts of a shared web hosting server. The only time a control panel should be concerned with the versions of these core software parts, is if one of those core softwares changes the way they are configured. If Apache suddenly changes to a JSON type VirtualHost storage system instead of their known VirtualHost containers - then the interface that the control panel provides will have to change to fit that configuration. How often does this happen?

As for PHP, I don't really understand where it fits in the control panel. A change in the way PHP interfaces with it's web server is a concern for the web server and not the control panel. Perhaps a better solution, and one that I strongly agree with, is that if the control panel is depending on PHP... then package it's own PHP into the control panel interface. If the control panel wants to use PHP 5.6 for all of it's control panel interfacing, then use PHP 5.6 in the control panel interface. If the control panel wants to use nginx as it's interfacing web server, then include it's own nginx system to provide that interface with the control panel.

The control panel itself should be self-contained. Sure it's going to depend on the existence of some system libraries and binaries (which can lead me into the topic of DirectAdmin supporting every Linux distribution under the sun, but that's veering way off topic). But when the control panel starts to mingle with the, what I'll call the "public Internet facing software", that's when problem arise.

If you are familiar with using pre and post hooks in control panels (which admittedly, DirectAdmin has a lot to offer here) then you basically have to understand that all a control panel is doing is a set of these pre and post hooks. If you go to create an account and enter a domain name, a username, a password, and a package. When you click submit all the control panel is doing is parsing that information through a series of pre and post hooks (most of which are invisible to server administrators, but they are there). It takes that information and configures a VirtualHost, configures the MTA and IMAP/POP3 services to work with this user and domain. If the only thing a control panel did was pass the information submitted from that create an account form into a hook - then essentially the server administrator would be responsible for fashioning the hook in such a way to configure the services as needed.

When you log into your DirectAdmin control panel interface, i.e. https://%server%:2222/, or whatever port you have this configured on. That's the control panel interface. That should be self-contained. It shouldn't care what web server or what web server version you are using (as long as the control panel knows how to add/modify/delete configurations for it). Or what PHP versions you have installed. It should all be self-contained.

This path that CustomBuild has taken in its reliance on DirectAdmin version, is a huge step backwards - in my opinion.
 
sparek said:
This path that CustomBuild has taken in its reliance on DirectAdmin version, is a huge step backwards - in my opinion.
Click to expand...
It doesn't need to be. As I understood it, the intention was to first fix things so the build in option (like it's now) is working without issues.
And then just issues DA releases when certain updates are needed (php, apache or whatever), even without new DA versions.

The idea behind it is good, because you can just do DA updates to update what is needed, even without updating DA itself. Kind of like custombuild did before but now all in one place.
Which is good, if everything works as designed with very little issues/bugs.

However, downside is that if there are a bit more important updates, and a DA update with bugs/issues is released (which is quite often nowadays I'm sorry to say), people have the bad choice to either wait until that is fixed, or update their php/apache/exim/whatever and with that forced to accept the DA version issues.

Maybe for this reason it's better to adjust the idea to maybe use kind like stuff, but have DA updates and software (PHP/Apache/Exim/whatever) updates seperately again, not bounded to DA, so they can update that without the need to have the DA binary updated to a version with issues.

They are more quick now with looking and trying to fix it, but I agree some seperate way of release updates can work faster/better, as it did before with custombuild.
 
What were the build issues before? I never had any issues before.

The issues I've seen on these forums are related to PHP updates being delayed in CustomBuild because updates to DirectAdmin were being delayed which delayed the ability to update PHP. To me that begs the question: Why does any version of DirectAdmin cripple you to not be able to use the latest version of PHP?

For disclosure... I'm not using CustomBuild for PHP. I use the RPMs provided by the Remi PHP repository to run my PHP environments. Because of the series of hooks that DirectAdmin graciously provides I am able to do that. It's not for everybody. I also don't use automatic updates for anything, I prefer a notification when a new version is available - which I've constructed such a system for me that does that. I don't typically jump on new versions of DirectAdmin as soon as they come off the press, because... again there's forum posts that go into detail about issues that are discovered after these releases. I don't mean anything negative because of that - I know what it's like to develop software and think you've got all of the bugs squashed, but until someone else uses your software and more people start using the software, they start to find more bugs that you didn't know about. I generally just prefer to let a lot of those bugs get ironed out before I update.

The point being, my PHP system and DirectAdmin are completely independent of each other. So why does the PHP provided in CustomBuild have to be tied with DirectAdmin the control panel?

Probably best to think of "DirectAdmin the control panel" as one thing and "CustomBuild" as another thing entirely. CustomBuild is essentially another product that DirectAdmin developers include with "DirectAdmin the control panel" when you subscribe to "DirectAdmin". Why can't CustomBuild be used to control all of the web facing (i.e. all the stuff besides the port 2222 stuff) applications? That's how it worked before.

To be completely fair, this isn't just a DirectAdmin problem. A lot of the other control panels out there want to tie you into their web facing application control systems, so you depend solely on them for updates. The other big control panel essentially does the same thing, they just don't tie it to their control panel version, but pretty much force you to use their RPM repositories.

There's nothing to stop anyone using DirectAdmin and CustomBuild from compiling their own versions of these web facing applications. If you want the latest version of PHP as soon as it's released, you can compile it on your own on a DirectAdmin server (Actually the Remi repository gets the updates before the official PHP release is made. Remi Collet is a developer with PHP). You don't have to use CustomBuild to accomplish this. CustomBuild certainly makes it easier.

I still think if DirectAdmin is going to tie all of their web facing application version updates into DirectAdmin updates, then that's going to be their downfall. The development track is just too different. What happens if a security issue is discovered in PHP that creates a PHP 8.1.4 to be released next week, but the DirectAdmin developers are in the middle of making a DirectAdmin 1.646 but they don't have everything ironed out yet? Does all of the DirectAdmin focused development get shifted to 1.647 while a DirectAdmin 1.645 update to DirectAdmin 1.646 become essentially a PHP update? What happens to all of the DirectAdmin development that's been tracked in 1.646? Or does the PHP 8.1.4 update get pushed back until the development on DirectAdmin 1.646 is completed?
 
you used to be able to update software independently from DA, now you can't i guess. (Since php versions are somewhat tied to CB)
 
sparek said:
What were the build issues before? I never had any issues before.
Click to expand...

DirectAdmin rolled back software versions several times already because of various issues a new version caused. Apache, Exim are in the list if I recollect it correct.
 
zEitEr said:
DirectAdmin rolled back software versions several times already because of various issues a new version caused. Apache, Exim are in the list if I recollect it correct.
Click to expand...
Why does tying these releases to DirectAdmin update fix things? How does that fix things?

Updates don't work as intended that is true. But I need it explained to me why tying these updates to DirectAdmin fixes this.

I remember one of the Apache issues. This was well before CustomBuild and DirectAdmin were merged at the hip. Apache would just die for some reason, nothing in the error_log. This was an Apache issue, it was listed in Apache's bug list. I believe setting a custom version for CustomBuild allowed you to downgrade and I think eventually the update was removed from CustomBuild so that Apache stayed a release behind. (I do believe the underlying issue for this is resolved now).

What was wrong with that procedure? What was wrong with the previous way CustomBuild did this? This "issue" can't happen with CustomBuild updates being tied to DirectAdmin updates?

I don't blame DirectAdmin for including that version of Apache in CustomBuild. Stuff like that happens. It wasn't DirectAdmin's fault. It was Apache's fault for not testing the release adequately. Stuff like that happens. You can test and test and test a product, but until it's out with the masses you can easily overlook bugs. It's like proofreading your own article. You can miss a word or misspell a word, but when you read it back to yourself - you read it like you want it to sound. Give the article to someone else to read and they can pick up on what's missing.

Now, when you're releasing updates and consistently having to release patches to those updates... that's a sign that maybe your testing apparatus needs to be better.
 
sparek said:
Why does tying these releases to DirectAdmin update fix things? How does that fix things?
Click to expand...

I don't work for DirectAdmin and neither am I their choice maker. So if you ask me, an user and administrator of own and my customers servers with Directadmin, a 3rd party developer for DirectAdmin, then my answer is simple:

If you want to be on a bleeding edge with new software versions, use alpha. Use current or stable if you want your server run tested software.

I don't have answers an all other questions of yours.
 
You must log in or register to reply here.
Back
Top