Please upgrade here. These earlier versions are no longer being updated and have security issues.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Is this broken? It breaks my entire forum on activation :-( [RESOLVED SQL strict mode issue)

edited November 2017 in Vanilla 2.0 - 2.8

I'm trying to install YAGA onto a forum and everytime I enable the application the entire forum seems to break. I then have to navigate to the config file to disable it manually as the entire forum website goes down. I've tried everything I know how to do (which admittedly isn't much) but I'm getting nowhere. I've had YAGA on previous forums where it worked perfectly and I'm desperate for it to work here too. Can anybody help me?

«1

Comments

  • @JessicaPlays

    Welcome to the community.

    I think it is working for most people (I know it works on our 2.3 forum.)

    'seems to break' isn't much of a clue as to where the issue lies.

    Add the line

    $Configuration['Debug'] = true;

    to your config.php file (or set false to true if it is there already.)

    This will enable a detailed error report, rather than the 'Something has gone wrong' page.

    Then enable YAGA again and let us know what error is reported.

  • edited November 2017

    Hi @whu606 ,

    Sorry, I realise I wasn't giving you much to go on. I've used Vanilla in the past but I won't claim I'm any good at it!

    I followed your steps and the debugger is active. But as soon as I enable the application it immediately throws me to the "Something has gone wrong. We've run into a problem and are unable to handle this request right now. Please check back in a little while. " default error. No more information than that :/

  • Odd - it normally shows a detailed error report.

    Do you have pretty urls enabled?

    If you are using a custom theme, can you try the default theme, with any plugins disabled.

  • edited November 2017

    Pretty URLS is enabled as far as I can tell. In my config I have "$Configuration['Garden']['RewriteUrls'] = true;". I've just changed my theme back to the default theme and disabled all Plugins. I still get the default error message when I try and enable the YAGA app :(

  • whu606whu606 MVP
    edited November 2017

    I don't get why there is no detailed error report (but that may well be because I don't know enough.)

    Could you check that there isn't a duplicate 'debug' line set to false in config.php.

    If you set it to false, is it the identical message?

    I'm flailing around here a bit. Maybe @R_J would have an idea.

    Do you know which version of PHP you are running?

  • edited November 2017

    There's only one debug line and its set to true. I can see debug info if I enable some plugins that don't work 100% so I'm certain the debugger is working.

    Setting the debug to false shows no information as expected, setting it to true only shows the aforementioned info and still nothing when I enable YAGA and the site crashes.

    I've attached an image of the screen I get the instant I enable YAGA. I get this regardless of plugins, theme and debug setting. If I refresh other tabs of the forum or navigate to any forum page I also get this error.

    My current PHP version is 7.1

  • whu606whu606 MVP
    edited November 2017

    Hopefully someone else will have an idea what is going on. It must be a situation specific issue, as it is working for me.

    My last suggestion would be to delete the current YAGA folder, and download the version from github:

    https://github.com/hgtonight/Application-Yaga

    just in case there have been any updates/changes not in the version on the site.

  • Thanks for trying to help me @whu606 . I was fully expecting it was something I'd done wrong so I'm feeling a little less stupid if it's a more complicated issue haha

    I've just deleted YAGA and installed the github version. Whilst it looked promisingly different again it crashed the site. Although this time I didn't get the standard Vanilla error screen.

  • @JessicaPlays said:
    There's only one debug line and its set to true. I can see debug info if I enable some plugins that don't work 100% so I'm certain the debugger is working.

    What you are seeing is the result of the Debugger plugin.

    Please make sure that the last line of /conf/config.php reads $Configuration['Debug'] = true;

    Then, if YAGA is enabled, go to any page and make sure your browser isn't showing you a cached page by trying to visit your home page in private mode

  • So following what you've said I'm still getting the same error as my above screenshot. I've tried private mode and a second browser to rule out cached pages.

  • Out of curiousity I just tried to enable YAGA on a clean install of Vanilla in a separate subdirectory. I'm getting the exact same outcome.

  • You should check your Server Errors Log ask you host where it is, there should be a link in the control panel from where you host your files.

    It is possible that it contains a syntax error. However it also is possible that you did not delete the entire YAGA folder before you installed the newer version from github and some files may have been moved and thus causing this problem.

    But you claim to still have it upon new install on a separate subdirectory so my money is on a syntax error .

  • Okay, I’m just away for a few hours but when I get the chance I’ll have a look.

    When you say Syntax errors do you mean in the YAGA files or in the main Vanilla Config?

  • In the YAGA app. Maybe the author made a mistake somewhere causing a fatal error.

    Syntax means in the code , like a missing comma or something else. It's hard to say unless you can read the error logs in your server for the specific error.

  • Okay so I delved around YAGA and couldn't work out any problems. I once again performed a clean install of vanilla in another new subdomain but this time I made a brand new database for it and didn't use the one click installer my host provided. Now with only a theme and YAGA installed I AM able to enable YAGA and see all the menu's without crashing the forum. But now there's 2 new issues.

    -Enabling Badges (the one thing I'm desperate to get working) crashes users that have a profile picture uploaded. They get the standard error screen and I can't find out any more information than that. If I delete their profile picture or disable Badges, they are able to access the forum again.
    -Reactions aren't working. Trying to press any of them produces an error pop up which I've attached.

    As I said this is on a clean install of Vanilla on a clean database with the most up to date YAGA download and with no major plugins enabled.

    Ideally I'd love to fix the first forum I had built because I was populating it with categories and posts, but I can migrate to this new database if I can get badges and reactions to work reliably.

  • One click installers are not recommended because they inject code could interfere.

    Try running yoursite.com/ utility/structure

    also whenever you modify anything, it is recommended to delete the .ini files in the cache , carefully not to delete anything else.

  • edited November 2017

    **I read that somewhere hence I tried a manual install.

    So I've just ran that /utility/structure URL and have the following information appearing in my dashboard:
    **
    _update GDN_Role Role
    set Type = 'applicant'
    where RoleID = '4';

    update GDN_Role Role
    set Type = 'member'
    where RoleID = '8';

    update GDN_Role Role
    set Type = 'unconfirmed'
    where RoleID = '3';

    update GDN_User User
    set Permissions = ''
    where Permissions <> '';_

    **I tried enabling the application but still no good. I have though managed to get better debug info. Now when the site goes down and I have to manually disable yaga in the config I can see the following message:
    **
    _Fatal Error in Gdn_Database.Query();

    Incorrect datetime value: '2017-11-11T16:48:18+0000' for column 'DateInserted' at row 1
    insert GDN_BadgeAward
    (BadgeID, UserID, InsertUserID, Reason, DateInserted)
    values (:BadgeID, :UserID, :InsertUserID, :Reason, :DateInserted)
    The error occurred on or near: /home/jess06121994/public_html/community/library/database/class.database.php
    422: if (!$message) {
    423: $message = $ex->getMessage();
    424: }
    425:
    426: trigger_error($message, E_USER_ERROR);
    427: }
    428:
    429: }
    430: _

  • This is to do with mysql mode.

    grep is your friend.

  • Ok this seems like a MySQL problem. The latest version 5.7 This appears to be because previous versions of MySQL supported dates like 0000-00-00 00:00:00 (by default) however 5.7.4 introduced some changes to the NO_ZERO_DATE setting. If you still have old data present when using a newer MySQL version, then random errors may crop up.

    you may needed to perform a query like this to reset all the zero dates to another date.

    # If the columns supports NULL, use that
    UPDATE table SET date_column = NULL WHERE date_column < '1000-01-01';
    
    # Otherwise supply another default date
    UPDATE table SET date_column = '1970-01-01' WHERE date_column < '1000-01-01';
    

    The NO_ZERO_DATE mode affects whether the server permits '0000-00-00' as a valid date. Its effect also depends on whether strict SQL mode is enabled.

    If this mode is not enabled, '0000-00-00' is permitted and inserts produce no warning.
    If this mode is enabled, '0000-00-00' is permitted and inserts produce a warning.
    If this mode and strict mode are enabled, '0000-00-00' is not permitted and inserts produce an error, unless IGNORE is given as well. For INSERT IGNORE and UPDATE IGNORE, '0000-00-00' is permitted and inserts produce a warning.
    As of MySQL 5.7.4, NO_ZERO_DATE is deprecated. In MySQL 5.7.4 through 5.7.7, NO_ZERO_DATE does nothing when named explicitly. Instead, its effect is included in the effects of strict SQL mode. In MySQL 5.7.8 and later, NO_ZERO_DATE does have an effect when named explicitly and is not part of strict mode, as before MySQL 5.7.4. However, it should be used in conjunction with strict mode and is enabled by default. A warning occurs if NO_ZERO_DATE is enabled without also enabling strict mode or vice versa. For additional discussion, see SQL Mode Changes in MySQL 5.7.

    Because NO_ZERO_DATE is deprecated, it will be removed in a future MySQL release as a separate mode name and its effect included in the effects of strict SQL mode.

    http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sqlmode_no_zero_date

  • actually you need to just set the mode. There is no need to update records.

    grep is your friend.

Sign In or Register to comment.