[3.0] Change likes to reactions...

[Oldiesmann]

This PR changes SMF's likes feature into a full-fledged reactions system.

Features:
Admins can add/remove reactions as desired (only limit is defined by the limits of the SMALLINT data type, which should be plenty)
For simplicity, it will use images in a reactions folder in the theme's images folder and will look for a $txt['react_{name}'] string for i18n (defaults to 'name' defined in the database if not found)

Work done so far:

• Database changes for install and upgrade
• Modified language strings

Still to do:

• Code modifications/additions to handle things
• Theme stuff
• Testing (this is alpha so not too worried about that yet)

Note that the upgrade uses a combination of db API functions and upgrade_query. In some situations (such as creating a table), upgrade_query is far simpler than the associated db API call.

[Oldiesmann]

Also cc @Sesquipedalian since this will require changes to the DB schema stuff in #8093

[asmith20002]

Good job. IMO this also should be done for 2.1

[live627]

2.1 is feature frozen and receives bug fixes only.

…

On Sun, May 5, 2024 at 9:52 PM asmith20002 ***@***.***> wrote: Good job. IMO this also should be done for 2.1 — Reply to this email directly, view it on GitHub <#8187 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADJNN5J44LLS3XBZI3OVHLZA4EAPAVCNFSM6AAAAABG3Y3IX6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJVGE4TIOJXGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Oldiesmann]

Fixed several bugs:

• Fixed admin center - fixed admin search referencing non-existent function; removed likes; added reactions menu item
• Fixed queries that still used the old format which had an optional identifier as the first parameter
• Fixed query in Stats that referenced a non-existent "reacts" column

Still need to update the Msg.php code to populate the variable which tracks how many of each reaction was chosen for a particular post

[tyrsson]

Got a typo in the string. "someoe"

[Oldiesmann]

@jdarwood007 @Sesquipedalian Can either of you explain what's causing the PHP-CS-Fixer check to fail here? It's not showing me an error and I can't get it to run locally (it just outputs whatever HTML is generated by SMF)

[Sesquipedalian]

I see you are working to fix code style issue, @Oldiesmann. I recommend that you simply install PHP-CS-Fixer and then use it to fix your files, like so:

php-cs-fixer fix --config=".php-cs-fixer.dist.php" --allow-risky="yes"

The --allow-risky="yes" bit is needed because we do use one rule that PHP-CS-Fixer classifies as "risky."

[Oldiesmann]

I see you are working to fix code style issue, @Oldiesmann. I recommend that you simply install PHP-CS-Fixer and then use it to fix your files, like so:

php-cs-fixer fix --config=".php-cs-fixer.dist.php" --allow-risky="yes"

It doesn't work if I run it locally because of all the index.php files SMF sticks within vendor and its various subdirectories - it just ends up pulling in SMF's own index.php file and generates whatever output is generated from that.

[Sesquipedalian]

Have you tried it recently? The .php-cs-fixer.dist.php file is configured to ignore anything inside the vendor dir.

[Oldiesmann]

If I run it from the directory with the now-fixed files, it complains that Settings.php isn't readable, and if I copy Settings.php to the directory, it'll just spit out the HTML for the error message saying SMF can't connect to the database. If I run it from a live local test board, it spits out HTML.

[Sesquipedalian]

Hm. You are correct. I will fix this soon.

[Sesquipedalian]

Please see #9114 for the fix to your problem, @Oldiesmann.