While I can't guarantee compatibility with PHP 7.4 right now, I can guarantee I will strive to have Tinyboard work on 7.4 when it reaches a stable release and makes its way to Linux distributions.
I can say that it runs perfectly fine on PHP 7.3 though. It's always been a priority of mine to make sure that Tinyboard (and by extension, AwsumChan) work flawlessly on current versions.
I noticed the error messages mentioned in https://github.com/vichan-devel/vichan/issues/363
I forked https://github.com/lifo101/ip
for the sake of PHP 7.4 compatibility, so errors related to that library should be a non issue. As for the errors related to Twig, that should not have been a problem for my fork since we migrated to Twig 2 - quite a while back, and I plan to upgrade to Twig 3 pretty soon (vichan is still using Twig 1.x).
If you notice any other errors while running it on PHP 7.4, let me know via this thread.
Wow those dramas.
But more importantly, wow this ancient lib. Do we really have no better (i.e. mainstream and maintained) lib or PHP native function to replace it altogether, that you have to do it yourself? Kudos to you.
Yeah, PHP does not offer the needed functions to replace that library. I decided to take up that library myself since it's abandonware that has been stable enough to not yield an issue until now. It's primarily used for CIDR based bans. I wouldn't call the library ancient, 2014 doesn't feel all that long ago.
When I run install.php it simply says-
"Trying to access array offset on value of type null"
and will not do anything. Any ideas???
No other error info? Interesting. I'll look into it. Also, have you ran composer install to make sure versions are up to date?
A seperate question.
The database schema is full of same old MyISAM. Would it still be compatible if I want to switch to InnoDB or at least Aria (MariaDB's take on MyISAM), in order to have their better efficiency and fail-safe mechanisms?
I mean, I assume all Tinyboard does to a db is your usual CRUD, or am I wrong because it actually does some engine-specific wizardry?
Yeah I plan to go straight to 10.4, or at least 10.3.
No other info, here is a working instance. I did the setup properly, ran composer.https://4usa.com/board/install.php
Enable $config['debug'] if you can. Should output a backtrace to the problem.>>143
Shouldn't be a problem since InnoDB has full-text now. I'd definitely test it first though. To be fair I think the only reason Tinyboard/vichan even use MyISAM is it is faster in read operations as opposed to InnoDB being faster in write operations, and that InnoDB didn't have full-text until 2013. I might consider switching the default to InnoDB in the future if it seems to work without issue.
I set it to true, same results and nothing in the error logs. Its funny how many people say they can fix vichan for 7.4, and no one did it tho. Must be 7.4 fucked vichan pretty good. One can only imagine what php 8.0 will do. A sinking ship.
Eh, don't give up on it now.
I guess I'll try building 7.4 so I can test it out. I'll have to install PHPBrew so I don't cause a fuck ton of clutter.
BUILDING one? What system does your machine run that don't already have 7.4 nicely prepared?
For Ubuntu Server I'm using the famous ppa:ondrej/php so I can have multiple versions coexist and easily switched back and forth at will. If anyone has even better recommendations feel free to enlighten us.
Ah, I almost completely forgot about that PPA, I'll use that instead since I'm having some shitty conflict issues with APT.
Yeah, I'm using Ubuntu.
Edit: Finding the cause of the error was pretty straightforward, and it should have been fixed before PHP 7.4 even rolled around imo. Needless to say, git pull and give it a try. If you encounter any further errors, let me know. I couldn't seem to get any to pop out.
Holy shit, it seems to work, I was able to install it on php 7.4.1 !!!! You should tell the main vichan git page that you fixed it!!
Sure, but I don't see them taking it with any sense of gratitude given the comments on the PHP Group's work on PHP.
Plus they'd have to do a lot more work than I do to get it running. Pretty sure there's a few dependencies that have to get upgraded, one of which I now maintain. This is where Composer becomes really useful.
Actually a month or two ago I switched an NPFchan instance from 7.1 to 7.4. It runs so far so good.
So I wonder if the above problem is mostly about install.php, since quite a few vichan forks explicitly state that that file is broken and it's better to do manual installations with raw install.sql and such.
Incredible job you did, do you still do the patreon thing? I will sign up for it later on, after I get some sleep. Yeah… I will leave it up to you how and if you wanna tell ppl how you got it working, lots of politics there. I bet ppl would be surprised to know that you got it working, as lots of others try but no one else got 7.4 working with any fork yet!
I kinda miss infinity-next as it was a bold move to do the whole thing from scratch with a "manstream" framework (Laravel, no matter good or not). Too bad it didn't last long.
infinity-next is still around. I just wouldn't say it has the same kind of following as vichan. Last I knew they had support for the latest version of Laravel.
Also, I still do have a Patreon account.
(Goes to check)
So he suddenly picked it up last October, after 3 whole years.
However 16chan.nl (as linked on that GitHub) is still invalid. I wonder when and where else there would be an demo site again so we can see how it's like now.
Thanks to everyone doing all kinds of infrastructural work here and there!
I just tried to post txt, the error is::
Unknown column 'board' in 'where clause'
then there is a bunch more error but your board settings dont allow for that much txt
[SQLSTATE] => 42S22
[Error code] => 1054
[Error message] => Unknown column 'board' in 'where clause'
[backtrace] => Array
 => Array
[file] => /var/www/html/board/inc/database.php
[line] => 25
[function] => error
[args] => Array
 => Unknown column 'board' in 'where clause'
then a bumch more stuff……………
By the way, "board" is the install dir. Does it just have to stay in the default "Tinyboard" dir?
Do you mind posting the full error? This is pretty odd to see, considering it's a SQL error not finding a column that should exist. Have you altered anything related to the database?
I've done text posts just fine on my local test install.
Sure, pls up the post char limit to a big page worth and I will post the whole message.
I am on php 7.4.1 as the phpinfo showed. Also I happen to use maria db, that shouldn't screw up anything tho right? Let me know when the char limit is raised and ill post the whole thing.
Post it to an unlisted https://pastebin.com/
post, that way it'll be syntax highlighted and can be set to expire after a day or so.
Neither PHP 7.4 or MariaDB should be causing this.
The ``bans`` table should have a column, `board`. For some reason, MySQL/MariaDB is saying that the column does not exist. I'd check to see if it's there. The most likely cause of the column missing is database alteration.
Destroyed and rebuilt server, it works now!
Thanks!!! Looks like you won the "space race" as your fork works fine on php 7.4.1 -
As mentioned earlier, let me know of any further errors related to Tinyboard in this thread. Glad I could help.
That old common error popped up again.
When I went into mod.php and try to install catalog theme, it gives an error on screen of "Trying to access array offset on value of type null".
by the way, by all means of course take ur time when you look at errors. Im not on a production site yet, I will just do a bunch of testing and see if I can find any errors.
Here is the error for when I try to create the catalog theme::::https://pastebin.com/eNHjcjwf
update— when I go down to php 7.3, the prob is instantly fixed. I was able to create the catalog theme, and rebuild. When I try to rebuild or create the catalog theme on php 7.4 it locks up with that error.
Maybe just skip php 7.4?? 7.4 will expire in 2 yrs anyway, and every prodject will want to go with php 8. Maybe the best strategy is to just skip 7.4 to save lots of time and effort that will only be good for the lifespan pf php 7.4 anyway??
Waiting to update code until PHP 8 is a far worse approach, considering it not only carries over all changes from PHP 7 but completely removes them, making it even harder in some cases to fix software bugs.
Most of these errors are happening not because of PHP 7.4 but because of bad code that's starting to get finally frowned upon. I'll get this fixed up.
Okay, pushed a commit that should fix that theme.
Awesome, looks like its fixed!!
Jesus, that thread on git got interesting at the end. Can I ask what comment you made that was accidentally deleted and also if Dr. Wheels found better futureproof fix as he says (claims?) can you kind of implement that futureproof fix too?
also, is the tinyboard v0.10.1 your version? Too bad the original tinyib don't transfer the repo to you, did you ever think of asking them to do that since like you say it definitely IS abandonware?
tinyboard I meant instead of tinyib
savetheinternet was always very protective of his work, and I don't ever see him willing to hand over the original repository if he ever makes a reappearance. I'm not concerned with that anyway. Any version of Tinyboard >= v0.10.0 has been from my repository.>>174
He's not actually future-proofing anything. He's just having vichan ignore errors in future versions of PHP rather than fix them. This will eventually lead to issues that will cause unwanted behavior. Errors are meant to point out broken, bad, or flawed code in programs. While this might make sense for vichan, which labels itself as having "next to no active development", I intend for Tinyboard to be in active development for the foreseeable future, so it makes no sense to "future-proof" it by ignoring errors. Instead, I will aim to fix them as they are spotted.
BTW please look at your commit here:https://github.com/Circlepuller/Tinyboard/commit/31e27a51c20ccceb59ed20c8cac829bfac1ce710
Line 357 and 377
This same thing is done TWICE? Or is it intentional?
Also should the modLog() at line 366 be moved to the last instead?
Those are intentional, they're for different queries.
As for the modLog() call, it's there because the board itself has been deleted at that point, and the actions taken after that are focused on cleaning up the aftermath.