Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

totally broken on php 7.4 #363

Closed
ghost opened this issue Nov 19, 2019 · 38 comments
Closed

totally broken on php 7.4 #363

ghost opened this issue Nov 19, 2019 · 38 comments
Labels
php7x-regression

Comments

@ghost
Copy link

ghost commented Nov 19, 2019 •
edited by ghost
Loading

Just as a heads up, things are totally broke for php 7.4

Deprecated: Array and string offset access syntax with curly braces is deprecated in inc/lib/IP/Lifo/IP/BC.php on line 105 Deprecated: Array and string offset access syntax with curly braces is deprecated in /inc/lib/IP/Lifo/IP/BC.php on line 105 Deprecated: Array and string offset access syntax with curly braces is deprecated in inc/lib/IP/Lifo/IP/BC.php on line 119 Deprecated: Array and string offset access syntax with curly braces is deprecated in inc/lib/IP/Lifo/IP/BC.php on line 119 Deprecated: Array and string offset access syntax with curly braces is deprecated in inc/lib/IP/Lifo/IP/BC.php on line 133 Deprecated: Array and string offset access syntax with curly braces is deprecated in inc/lib/IP/Lifo/IP/BC.php on line 133 Deprecated: Array and string offset access syntax with curly braces is deprecated in inc/lib/IP/Lifo/IP/BC.php on line 147 Warning: Cannot modify header information - headers already sent by (output started at board1/inc/lib/IP/Lifo/IP/BC.php:105) in oard1/inc/display.php on line 104 Deprecated: Unparenthesized a ? b : c ? d : e is deprecated. Use either (a ? b : c) ? d : e or a ? b : (c ? d : e) in inc/lib/Twig/Node.php on line 42 Deprecated: Unparenthesized a ? b : c ? d : e is deprecated. Use either (a ? b : c) ? d : e or a ? b : (c ? d : e) in public/board1/inc/lib/Twig/Node.php on line 198
@john-clever
Copy link

copypaste is too busy with his little fight to give a shit about vichan. It was already dead, but now vichan is officially defunc'd.

The best would be to create a fork of it and try to update little by little. I'd not mind helping.

@ctrlcctrlv
Copy link
Member

At least the problems seem to be simply syntactical, so easily fixable in a PR

Make sure to read the README for information about current project status

@ghost
Copy link

ghost commented Dec 1, 2019

Gives me anxiety that every PHP update breaks shit.

If that's the only problems, I think I could even fix this though. But who knows how bad it really is.

@ctrlcctrlv
Copy link
Member

They keep updating the language spec with every release with no regard for old code like ours. It's a shame no one seems to have forked PHP5. Their actions are reckless.

@ghost
Copy link

ghost commented Dec 28, 2019 •
edited by ghost
Loading

For anyone on Arch, eventually the PHP 7.3 packages will break, so I'm leaving some instructions on how to compile the PHP 7.3 packages

https://git.archlinux.org/svntogit/packages.git/log/?h=packages/php

Here you can see all the changes made to the source files used to create the official PHP packages in the official Arch repo.

We want to get the last commit of the files used to create the 7.3 packages. So in this case, I just did:

git clone https://git.archlinux.org/svntogit/packages.git
cd packages
git reset --hard ee5ad6f99389176fa0927d9a85d2094df8caa4a1

You now have the old files they used to build the official PHP 7.3 packages, just run makepkg -s in the directory with PKGBUILD, and it will build them, you can install them with sudo pacman -U package_name.tar.xz and they integrate with the package manager exactly the same as the official packages (because you basically built an official package), it's that simple.

This builds the following packages:

pkgname=('php'
         'php-cgi'
         'php-apache'
         'php-fpm'
         'php-embed'
         'php-phpdbg'
         'php-dblib'
         'php-enchant'
         'php-gd'
         'php-imap'
         'php-intl'
         'php-sodium'
         'php-odbc'
         'php-pgsql'
         'php-pspell'
         'php-snmp'
         'php-sqlite'
         'php-tidy'
         'php-xsl')

@ctrlcctrlv
Copy link
Member

I wrote the PHP Group a message:

https://github.com/vichan-devel/vichan/wiki/The-PHP-Group-has-no-idea-what-they-want-PHP-to-look-like,-so-keep-reinventing-it,-meanwhile-Vichan,-and-countless-other-projects-suffer!

@jsmmo
Copy link

jsmmo commented Jan 13, 2020

noobs.

If anyone here would know how to run web pages you wouldnt have a problem. But instead youre trying to install things on arch which are not gonna help you folks lol. That is what i expect from "image board" devs who arent real devs.

Why do you expect a such old and unmaintained software will work with the latest release of php7? you are free to use php5.6 but i feel like you folks didnt even know how to get the correct php version for your application installed.

This thread and all associated threads anywhere are just showing off how youre unable to do real stuff expect hacking shit together. Probably it is no wonder if you actually are trying to run this bad code (and it was bad 10-20 years ago...)

@ghost
Copy link

ghost commented Jan 13, 2020

@jsmmo
But instead youre trying to install things on arch which are not gonna help you folks lol.
I run an actively used imageboard with vichan on Arch.

There's nothing special or specific about Arch in this regard except that it keeps up with the latest stable releases of PHP. Arch itself has never given me problems in this regard, it's upstream PHP.

Our only option is staying on ancient distros still shipping old PHP packages (RHEL/CentOS/Debian) but how long can you do this and avoid newer PHP? Or build our own packages of older versions of PHP, or yes, hack vichan into compliance with every new PHP version that breaks compatibility with older PHP code.

5 -> 7 breaking stuff? Ok whatever

Minor releases like 7.4 randomly breaking compatibility all the time because they don't like some random syntax anymore? Why?

@jsmmo
Copy link

jsmmo commented Jan 13, 2020

If you want to run it on the hottest php major version then you have to upgrade.

You didnt even update to 7.0 and now expecting it to work out of nowhere. Just update. Else build 5.6 from the sources :1) If you want to make your life easy just use docker (or your arch hacked container of your choice). Its not like its not possible anymore... arent there any repos building old php images for hacky distros?
This is more a distro problem that youre not getting a python2 kind of php than php changing things over the last 5 years.

@ghost
Copy link

ghost commented Jan 13, 2020

If you want to run it on the hottest php major version then you have to upgrade.
No? I have to fix vichan's source code to be compatible.

I have to actually stop my OS from upgrading to the latest PHP version.

If you want to make your life easy just use docker
It'd still be the same solutions to the same problem, just contained to a VM or "container".

  • Having to use old distros/packages
  • Fixing vichan source code to be compatible

These are the only two solutions.

@imliam
Copy link

imliam commented Jan 13, 2020

The only things pointed out in here are deprecation warnings - not BC breaks. Have you tried turning off deprecation warning so it doesn't output to the buffer?

@ctrlcctrlv
Copy link
Member

@imliam's idea sounds good, and I have no problem adding e.g.:

error_reporting(E_ALL & ~E_DEPRECATED);

to the top of inc/functions.php. However, I remain highly skeptical of PHP Group, and assume they plan to remove what's currently deprecated at some point, which will break this. At least, I will post this as a possible interim solution.

@ctrlcctrlv
Copy link
Member

Do you mind testing the code above @z0z0z ?

By the way, all the downvoters here and on Reddit, you have no idea what makes a programming language good or valuable and that's why you like PHP and think the PHP Group makes good decisions. Meanwhile JavaScript, C, Python (since 2008), Ruby (I think), all these language have managed to do something PHP Group is too inept to do: decide on a stable spec.

@jsmmo
Copy link

jsmmo commented Jan 14, 2020

@imliam's idea sounds good, and I have no problem adding e.g.:

error_reporting(E_ALL & ~E_DEPRECATED);

to the top of inc/functions.php. However, I remain highly skeptical of PHP Group, and assume they plan to remove what's currently deprecated at some point, which will break this. At least, I will post this as a possible interim solution.

Just stop.
Let the project die or look for actuall php guys who know what they are doing. You clearly not. Please switch to Javascript (which is more unstable but you wont care). Then you have a modern code base and you can reopen this issue in 10 years again.

@ctrlcctrlv
Copy link
Member

You don't call the shots here.

JavaScript is not unstable at all. The earliest JavaScript code still works. If you have all the libraries everything runs great.

Take a look at Dynamic Drive in any modern browser. What a lovely old site, innit? Really reminds me of my childhood. All the scripts still work just fine. I linked you one last updated in 2005. This is back when they were known as "DHTML".

PHP scripts from 2005 don't run in a modern interpreter. What's the problem here? I don't need some "actual PHP guys" to tell me that the PHP Group's piss on my leg is actually rain water.

@ctrlcctrlv
Copy link
Member

ctrlcctrlv commented Jan 14, 2020 •
edited
Loading

By the way @jsmmo, it's laughable that a kid who registered his GitHub account under the name "JavaScript MMO" is both (a) knocking JavaScript and (b) trying to tell me how to run this project. At my previous job I patched a PHP extension written in C. I have written an nginx native plugin as well. You've done bare basic web development yet think you know everything.

Try being older than 23 and seeing projects you worked on in your youth rot because of terrible administration by the committee designated to look over the programming language's main implementation.

@jsmmo
Copy link

jsmmo commented Jan 14, 2020 via email

@ctrlcctrlv
Copy link
Member

Back when I developed imageboard software as a job, I considered implementing an imageboard in Lua, to be run in Nginx+Lua. So not quite what you propose, but close. Anyway, if running composer makes you an expert, go give someone else your wisdom.

@jsmmo
Copy link

jsmmo commented Jan 14, 2020 via email

@ctrlcctrlv
Copy link
Member

Friend, I'm not even the original developer. In fact I'm not even developer №2. I'm developer №3. All of the important decisions had already been made by the time I became maintainer; in fact, even my good friend Marcin (№2) was constrained mightily by the original code.

In any event, static dependency management was the only way to do things in 2010. Are you even old enough to remember 2010? Composer's initial release was in 2012! 😂

@jsmmo
Copy link

jsmmo commented Jan 14, 2020 via email

@ctrlcctrlv
Copy link
Member

Vichan is not for sale.

@ghost
Copy link

ghost commented Jan 14, 2020 •
edited by ghost
Loading

We need to contact STI and takeover the PHP council

@ECHibiki
Copy link

I don't see the outrage. Everyone and their mother knows Vichan is legacy and intended to work on poor performing versions of PHP. What are you even going to say when PHP8 is released with JIT and Vichan still uses Twig1.3 from 2010?

@ctrlcctrlv
Copy link
Member

What are you even going to say when PHP8 is released with JIT and Vichan still uses Twig1.3 from 2010?

I'm going to say: the fact that my code, which is only ten years old, doesn't work with minimal tinkering is a disgrace. Just as I've said today.

Lua is another language which has managed to maintain a stable spec, despite its initial release having happened in 1993. They manage to have a JIT just fine. The PHP Group are simply lazy and believe their own language to be inferior, so they make it so through their decisions.

@ctrlcctrlv
Copy link
Member

Let's say you paint a beautiful picture on a nice piece of canvas.

We have such paintings that are hundreds of years old. Nobody comes out and says, "oh they should have used these modern paints which are much better blah blah blah" and throws away the painting.

My programs and my patches are my art. A lot of my programs actually literally generate art, they are my Python scripts intended for use with FontForge or GIMP (and then FontForge via autotrace).

Vichan is one of my paintings. I put a lot of effort into it as a young man, as did many others. You think that post.php looks ugly? You think that inc/functions.php has too many functions? You think that the way we used PDO is bad?

Truly I tell you, I don't give two shits about such feelings. This code is valid, this code worked on real world systems, this code powered the websites of my youth. Your disregard for the past offends me, take your JIT (shit?) and shove it where the sun don't shine.

GCC can manage it. Lua can manage it. JavaScript can manage it. Python can manage it, with asterisk. Perl can manage it. (In fact, I recently used a Perl program from 2004!)

So why can't PHP manage it? Let me say it again: because they believe in themselves what their enemies say, that their language is poorly designed.

@ECHibiki
Copy link

well shucks, I'm sorry that you're insulted that I don't share your pov but frankly I've fixed more than enough of your and others bugs in the software that php updates don't really phase me anymore

@ctrlcctrlv
Copy link
Member

If you think I'm ``phased'' you really have no idea what I'm talking about.

If you think I'm incapable of fixing these ``bugs'' (read: breakage intentionally foisted upon us by a corrupt, aloof hierarchy with no respect for history), you have no idea what you're talking about.

This isn't about any one bug. But yes of course, I happily accept patches and always have.

@ECHibiki
Copy link

Having fixed my own fork to work on php7.4 the changes were nothing that incredible to blow my junior mind. It's certainly put upgrades to Twig as an important concern since the update has impacted template formatting, but i mean... why did no one ever update this to work with future releases... If anything I put my difficulties with this PHP update on the vichan team because I can't proceed with anything more than a hack fix until I modernize this aspect.

I don't really care for the somewhat narcissistic belief that PHP owes you anything. The arguments seems somewhat manipulative if anyone even glances over the projects readme for a second

@ctrlcctrlv
Copy link
Member

A good programming language owes its users backwards compatibility. It's an implicit contract.

They owe me it, yes, if they will be a good programming language. If they want to be "hip", they can go onto the garbage heap. I'm not expecting them to patch Vichan, I'm expecting them to uphold their duty to the community to maintain a stable language standard.

I bet the scope resolution operator is still called T_PAAMAYIM_NEKUDOTAYIM, is it not? So they will keep in some changes based on BC, but not others because they're "bad design". 🙄

@ghost
Copy link
Author

ghost commented Jan 14, 2020 •
edited by ghost
Loading

@ctrlcctrlv I stand with you! I put your video on 4usa.com We must save the internet and replace the PHP Group! :)

@ctrlcctrlv
Copy link
Member

Thank you @4usacom and @StephenLynx for the solidarity.

@Appleman1234, please don't bother sending any of your PRs upstream. If we can't agree on this basic of an issue, I can't trust your judgment. Yes, I did notice your treason for Reddit upboats, and I am not impressed.

2020-01-15-104452_2697x656_scrot

@ghost
Copy link
Author

ghost commented Jan 17, 2020 •
edited by ghost
Loading

@ctrlcctrlv You are totally right, and the reddit ppl who want to impress the world by trying to counter your valid points are doing so for entertainment, not the utility of truth. In other words... they are autistic idiots trying to make a name by challenging the champ (you)!
@ECHibiki - where is this phantom fork that you got to run with 7.4 as you told ctrlcctrlv ?? It is no where to be found. The only fork on your repos says not to use it.

To everyone ----
So @Circlepuller made a fork and uses composer in it, he did shitloads of work on his fork. Even then it appears to be broke on php 7.4.1 which is nuts. Install.php simply says "Trying to access array offset on value of type null" and locks up. Anyone know what the heck that is? //edit: Oah the error is a specific php 7.4. one, many people are trying to figure it out the error for other projects as well. Nice job PHP GROUP (roll eyes emoji) .

@Circlepuller
Copy link

I'd like to follow up on the comment by @4usacom and say that my repository has seemed to resolve any immediate issues brought on by PHP 7.4.

@ctrlcctrlv
Copy link
Member

@Circlepuller Your fix is not good. I have committed a better fix, which consists of two parts:

  • Fix the actual deprecations. a2ba038
  • Make it so future deprecations will no longer be treated as errors. 5e80904 (thanks @imliam for idea)

I consider this issue closed. Note that I still consider the PHP Group to be wreckers.

@ctrlcctrlv
Copy link
Member

Oh, so $board can be NULL there. Duh. Sorry, ignore my comment (Circlepuller@98d1b4e#commitcomment-36869981), we will cherry-pick those two. Thank you @Circlepuller

@Circlepuller
Copy link

Not a problem, haha.

@ctrlcctrlv
Copy link
Member

OK, merged :-)

Seems I accidentally deleted a previous comment of yours, GitHub was acting up for me. Sorry

@h00j h00j mentioned this issue Feb 13, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
php7x-regression
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@Circlepuller @ctrlcctrlv @imliam @ECHibiki @jsmmo @john-clever