PHP 7 and Osclass

[Aficionado]

While in french, the Charts are fully understandable to all.

http://www.journaldunet.com/developpeur/php/php-7.shtml

[Aficionado]

As far as we know, there are no known issues with PHP 7. Deprecated warning messages are fixed in 3.5.8

Daniel, could you check the following because i can't:

PHP 7 RC 5, with GD lib enabled (since imagick is not available for some reason).

I try to upload a 2.5 mb image and fails with the error "File Empty". I can upload smaller images. The size allowed is 8192 within Osclass and 50 mb within PHP.

Not sure this is an Osclass problem or some setup with PHP 7 and RC.

Could you test a bit uploading large images, if you have some spare time.

Thanks !

[_CONEJO]

I did not have any problem uploading 4.1Mb images

This is my configuration : http://imgur.com/bVnA4z9

I'm using the "php:7.0-apache" docker image with some modifications, I'm pretty sure it's not updated with the version of the last RC, but I really don't know which PHP7 release is running at this moment

Code: [Select]

FROM php:7.0-apache

# install modules
RUN apt-get update && apt-get install -y \
        libfreetype6-dev \
        libjpeg62-turbo-dev \
        libmcrypt-dev \
        libpng12-dev \
    && docker-php-ext-install iconv mysqli mbstring mcrypt\
    && docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/ \
    && docker-php-ext-install gd
RUN apt-get install -y cron
RUN apt-get install -y mysql-client
RUN apt-get install -y vim nano
RUN apt-get install -y libgmp-dev
RUN a2enmod rewrite
RUN a2enmod ssl
RUN docker-php-ext-install pdo_mysql


RUN ln -s /usr/include/x86_64-linux-gnu/gmp.h /usr/include/gmp.h
RUN docker-php-ext-configure gmp --with-gmp=/usr/include/x86_64-linux-gnu
RUN docker-php-ext-install gmp


RUN apt-get install -y supervisor
COPY config/supervisor.conf /etc/supervisor/conf.d/supervisor.conf


COPY config/php.ini /usr/local/etc/php/php.ini

CMD ["supervisord", "-n"]


[Aficionado]

I did not have any problem uploading 4.1Mb images

This is my configuration : http://imgur.com/bVnA4z9

I'm using the "php:7.0-apache" docker image with some modifications, I'm pretty sure it's not updated with the version of the last RC, but I really don't know which PHP7 release is running at this moment

Probably it is related to what i run, CloudLinux and LiteSpeed webserver.

Thank you

[SteveJohnson]

Thank you for update. Just to let you know, i'm interested too but i'm gonna wait for the stable release of php 7

[Aficionado]

Thank you for update. Just to let you know, i'm interested too but i'm gonna wait for the stable release of php 7

Me too i'm waiting for a stable version (in 2 weeks from what they say, and a few more to be available to all builds), those are some 3-4 hours tests just to see if any major problems exists. For my Wordpress and Osclass.

And i will not use PHP 7 immediately when available, i will wait others to do the debuging on their live systems. 

[Aficionado]

While this is for Wordpress, i guess it will be about the same with Osclass.

In my WP Dashboard with PHP 5.6: memory used 44.45 of 250 mb

With PHP 7 RC 5: 9.23 of 250 mb

That is 1/4 of memory of 5.6.

I can't believe it. Could be a miscalcucation somehow.

[_CONEJO]

It could be an extreme case, maybe WP is really optimized for PHP7, not sure as I didn't try it yet.

I've seen some charts about the performance improvement of PHP7 (in a generic environment) and they really looks great, like a big step from 5.6

[Aficionado]

It could be an extreme case, maybe WP is really optimized for PHP7, not sure as I didn't try it yet.

I've seen some charts about the performance improvement of PHP7 (in a generic environment) and they really looks great, like a big step from 5.6

As somebody wrote, "We can't AFFORD not to switch to PHP 7". If you think of it, he is right. Imagine the boost everybody will get in speed and memory (that is $$)  and also imagine what that means for hosting providers. An X2 upgrade of their services  for free (also $$) !!!

[SteveJohnson]

Damn it... all this sounds so unreal. Amazing!

[Aficionado]

Hi,

After doing the last evaluations in the RMs circle before going for 7.0.0
RTM preparations, we came to the conclusion that the current state does not
look reasonable to be packaged as the final release.

The RCs before RC6 was looking acceptable, which gave the reason to announce
the planned RTM date on Nov 12th as final. From the todays perspective, the
most of the issues discovered and fixed since RC6 are still minor by
themselves - 7 crashes (bug #70805 rather critical), and 3 functionality
regressions. However, given the amount and the combination of them
altogether, the state is in our opinion unsuitable for starting the life
cycle of the next major.

Thus, resuming the pre-release cycle seems in our opinion the right thing to
do ATM. Hence this writing to inform the community about the intention and
to gather the opinions. PHP 7 is still going down the home stretch and is
very close to the finish, the next RC can be well the last. Though we'd
better ensuring the quality as many times as needed before, instead of
casually disservicing the consumers.

Regards

Anatol

[Aficionado]

PHP 7 has been delayed for the end of the month, tomorrow (12 of Nov) there will be just a RC 7 instead of the Release.

So i wouldn't expect PHP 7 to be available to the hosting companies and for production sites, until maybe January of 2016. That is in 2-3 months from now.

 

[SmaRTeY]

Welllllllll

we'd better ensuring the quality as many times as needed before, instead of casually disservicing the consumers

I agree

[Aficionado]

Welllllllll

we'd better ensuring the quality as many times as needed before, instead of casually disservicing the consumers

I agree

As long as PHP 7 will not be a PHP 6 like fiasco. (i believe it is not)

[SmaRTeY]

I believe in learning experiences so if most PHP devs working on 6 are now working on 7 I think we'll be alright haha
Ohwell, the specs are very interesting and it is nice to see progress anyway....

Welllllllll

we'd better ensuring the quality as many times as needed before, instead of casually disservicing the consumers

I agree

As long as PHP 7 will not be a PHP 6 like fiasco. (i believe it is not)