Announcement

Collapse
No announcement yet.

Afer upgrading to 4.2.0 I can't run tools.php

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • postcd
    replied
    I was able to sort out this crappy error by doing upgrade (uploading my vbulletin /install directory). so hope it will help anyone.

    Leave a comment:


  • Wayne Luke
    replied
    Originally posted by DannyITR View Post
    Thank you for the reply. So what is my course of action right now? Do I need to wait for the 4.2.1 release? I need the new tools.php to fix my site.
    Open a support ticket please.

    Leave a comment:


  • DannyITR
    replied
    Originally posted by Wayne Luke View Post
    Due to the way the files are built, these presented a security risk and have been removed.
    Thank you for the reply. So what is my course of action right now? Do I need to wait for the 4.2.1 release? I need the new tools.php to fix my site.

    Leave a comment:


  • Wayne Luke
    replied
    Originally posted by DannyITR View Post
    In the bug report it reads:


    But I cannot find the files he speaks of. Where can I download them?
    Due to the way the files are built, these presented a security risk and have been removed.

    Leave a comment:


  • DannyITR
    replied
    Originally posted by Wayne Luke View Post
    I've recreated this issue and added it to JIRA here: http://tracker.vbulletin.com/browse/VBIV-15180

    What was the need to run tools.php?
    In the bug report it reads:
    Use these files and this init.php goes in the install directory.
    But I cannot find the files he speaks of. Where can I download them?

    Leave a comment:


  • Boofo
    replied
    Originally posted by Paul M View Post
    Or remove/rename the entire install folder, it isnt requierd for the day to day operation of vB.
    I remove everything in the install directory after every upgrade except for 4 files:

    .htaccess
    index.html
    functions_installupgrade.php
    mysql-schema.php

    Good habit to get into.

    Leave a comment:


  • adabros
    replied
    Hi!
    excuse, for admin privileges whitout tools.php , what are i doing?

    Leave a comment:


  • Paul M
    replied
    Or remove/rename the entire install folder, it isnt requierd for the day to day operation of vB.

    Leave a comment:


  • borbole
    replied
    Originally posted by mikeinjersey View Post
    that's kinda weird though...anybody that has our customer number could re-run the update over and over again without our knowledge.. (no password needed)
    Remove the upgrade.php file if you are so concerned about it.

    Leave a comment:


  • mikeinjersey
    replied
    Originally posted by Wayne Luke View Post
    It will proceed to the final step to reimport style, languages and additional products. This is normal and won't hurt your system.
    that's kinda weird though...anybody that has our customer number could re-run the update over and over again without our knowledge.. (no password needed)

    Leave a comment:


  • Wayne Luke
    replied
    Originally posted by mikeinjersey View Post
    #1 I noticed in PhpMyAdmin just now that for the Collation, 40% of my files are UTF8 and 60% are Latin Swedish. It's probably been working fine like this for years...and I saw another thread of others saying similar...not really making it a big deal. But Vb's response makes it seem like a serious issue. Should I really change them all from 1 to another ? Is there a quick way to do them all at once ?
    Ideally they should have all the same collation. Different collations can cause problems in the future because vBulletin will simply use the default for the database and you shouldn't mix collations in the same table. The places where this causes the most issues is double-byte languages like Chinese, Japanese, Arabic and Hebrew.

    #2 I still haven't received a response in my support ticket yet about this specific issue : After successfully upgrading to 4.2.0 and having no errors using /install/upgrade.php to do so. I notice today that if I re-visit that specific file again , it gives me the option to upgrade to 4.2.0 again. (even though i'm already 4.2.0 ) Is that normal ? If not, what specifically should it say when revisiting /install/upgrade.php after successfully upgrading to the latest version ?
    It will proceed to the final step to reimport style, languages and additional products. This is normal and won't hurt your system.

    Leave a comment:


  • mikeinjersey
    replied
    Wayne, I mentioned in last post...I specifically deleted the crashed DB and everything is working fine. The only issue is with the 270MB overhead in the INNODB files.

    update:

    good news. I changed them all to MyISAM and re-ran mysqlcheck.. and no errors now. The 270MB overhead showing on the Admin CP - Repair Optimize screen is gone now on all those files.

    everything is running fine.. but, 2 more and i'll be out of your hair for the rest of the week.

    #1 I noticed in PhpMyAdmin just now that for the Collation, 40% of my files are UTF8 and 60% are Latin Swedish. It's probably been working fine like this for years...and I saw another thread of others saying similar...not really making it a big deal. But Vb's response makes it seem like a serious issue. Should I really change them all from 1 to another ? Is there a quick way to do them all at once ?

    #2 I still haven't received a response in my support ticket yet about this specific issue : After successfully upgrading to 4.2.0 and having no errors using /install/upgrade.php to do so. I notice today that if I re-visit that specific file again , it gives me the option to upgrade to 4.2.0 again. (even though i'm already 4.2.0 ) Is that normal ? If not, what specifically should it say when revisiting /install/upgrade.php after successfully upgrading to the latest version ?

    thanks much. (going to bed)
    Last edited by mikeinjersey; Sat 26th May '12, 11:48pm.

    Leave a comment:


  • Wayne Luke
    replied
    Originally posted by mikeinjersey View Post
    This recent thread acknowledges you guys knew about this all along with InnoDb -

    https://www.vbulletin.com/forum/show...04-Isam-innodb

    that future tables will be created as InnoDb without us even knowing.. Did you guys not think of people running Repair / Optimize tables in AdminCP and having a similar catastrophic innocent like I had today ? That command only recognizes MyIsam tables..

    ---If I could get a reply about what to do before going to bed...that'll be great. Should I dump and change those tables from InnoDB to Myisam ? When I run MsqlCheck in the future, i'd like everything to be repaired in 1 process.
    You should contact your hosting provider and have them repair the database.

    MyISAM, INNODB - Doesn't matter if the database is properly maintained. However if you want to switch it is your choice. You would have to fix the crashed tables first. If you want your tables to MyISAM, then you should configure your database to use MyISAM as the default storage engine. MySQL AB made the choice to change the default storage engine to INNDOB, not vBulletin. We just use the default type.

    The Repair and Optimize tools in the Admin CP should not be run on a regular basis. They are repair tools not maintenance tools.

    Leave a comment:


  • mikeinjersey
    replied
    I appreciate the patience & help at this late hour..

    So nobody so far thinks this is an issue with MySql ? Everything seems turned on and off ok ? Do I need to enable anything according to that log file ? Like mentioned before all my other mysql sites are working fine. I copied and pasted the output of Show Engines at the bottom of this post.

    Open phpmyadmin and next to the list of tables you will be able to see something like myisam / innodb / other next to each table. This is the storage engine.
    Sonic, you are right ! All these tables mentioned above that have 277MB of overhead in them ARE innodb. This is not the first time this has happened either. Seems like everytime there's a new VB update that adds new tables, their created as InnoDb . The others are still MyIsam.

    what to do now ? Says I upgraded to 4.2.0 yesterday with no errors . Yet I have all these InnoDb tables.

    Are these specific tables ok to be dumped...or no ? Best way to change to MyIsam ? and how to make sure in the future others are always created as MyIsam ?

    Originally posted by Lynne View Post
    Did you import your backup over the existing database or create a new one for the import (you should never import over an existing database)?
    Lynn and the other dude, I mentioned several posts up that , that database crash was from the old DB. I completely deleted that database, and created a new one from yesterday's backup. My forums run completely fine, the CMS articles show up fine too. But I need to fix this InnoDB thing. The problem is solely with InnoDb it appears. I'm not sure if I need to run the VB 4.2.0 upgrade again because of this though ?

    Show Engines results -




    auto-rehash TRUE
    auto-vertical-output FALSE
    character-sets-dir (No default value)
    column-type-info FALSE
    comments FALSE
    compress FALSE
    debug-check FALSE
    debug-info FALSE
    database (No default value)
    default-character-set auto
    delimiter ;
    vertical FALSE
    force FALSE
    named-commands FALSE
    ignore-spaces FALSE
    init-command (No default value)
    local-infile FALSE
    no-beep FALSE
    host (No default value)
    html FALSE
    xml FALSE
    line-numbers TRUE
    unbuffered FALSE
    column-names TRUE
    sigint-ignore FALSE
    port 0
    prompt mysql>
    quick FALSE
    raw FALSE
    reconnect TRUE
    socket (No default value)
    ssl FALSE
    ssl-ca (No default value)
    ssl-capath (No default value)
    ssl-cert (No default value)
    ssl-cipher (No default value)
    ssl-key (No default value)
    ssl-verify-server-cert FALSE
    table FALSE
    user (No default value)
    safe-updates FALSE
    i-am-a-dummy FALSE
    connect-timeout 0
    max-allowed-packet 16777216
    net-buffer-length 16384
    select-limit 1000
    max-join-size 1000000
    secure-auth FALSE
    show-warnings FALSE
    plugin-dir (No default value)
    default-auth (No default value)

    - - - Updated - - -

    This recent thread acknowledges you guys knew about this all along with InnoDb -

    https://www.vbulletin.com/forum/show...04-Isam-innodb

    that future tables will be created as InnoDb without us even knowing.. Did you guys not think of people running Repair / Optimize tables in AdminCP and having a similar catastrophic innocent like I had today ? That command only recognizes MyIsam tables..

    ---If I could get a reply about what to do before going to bed...that'll be great. Should I dump and change those tables from InnoDB to Myisam ? When I run MsqlCheck in the future, i'd like everything to be repaired in 1 process.

    Leave a comment:


  • Lynne
    replied
    Did you import your backup over the existing database or create a new one for the import (you should never import over an existing database)?

    Leave a comment:

Related Topics

Collapse

Working...
X