Blog Documentation Book a Demo
Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

cannot activate extensions

2»

Comments

  • ccmehilccmehil
    great to hear!
  • jacmgrjacmgr
    I am having same problem with extensions not activiating. When I check them they appear to activate, but extensions.php is not updated, and of course their effects are not shown. When you go back to setup extensions, none are checked. Upgraded from pre-relaease. All discussions and comments appear fine. All users afine. All categories fine. Just seems to be problem with extensions. 1) the conf folder and all contents within it are 777 2) Check for updates shows me running current version. www.therentalcalendar.net/forum
  • lechlech ✭
    jacmgr, try bringing down the permissions for the files within the /conf/ directory to 666 and see if that helps, some servers don't like granting that level of permission to files which could be executed by anyone who has access to them or not.
  • MarkMark Vanilla Staff
    Good point, lech.

    I've just updated the troubleshooting tips to say as much...
  • jacmgrjacmgr
    Ok. Here is new info. Changeing extensions.php to 666 (or anything else) has same effect. No sticky extensions. Changing the conf folder to anything less than 777 results in the vanilla setup screen appearing. I have been using this host for a long time. I have always been able to change permissions through ftp etc... for many different kinds of software (mambo, joomla, open realty mostly) Is there instructions for doing a complete fresh install and then connecting back to the original database with all the discussions, users, comments? Don;t know if the phpinfo tells you anything, but here it is: http://therentalcalendar.net/forum/phpinfo.php Browser: IE 6.0 I appreciate your help. Thankx jacmgr
  • MarkMark Vanilla Staff
    Are you not just applying the 777 to the conf folder, but also the php files within it?
  • timberfordtimberford
    im getting the exact same issues as jacmgr. i have found that extensions can be turned on manually but i cannot use the vanilla admin to enable/disable them. the permissions are set to 777 for all files in the conf folder and the folder itself. incidently it was working fine until i installed the panel lists extension, it broke my forum so i went in and manually removed it from the conf file. ever since then the extension manager has been broken.
  • timberfordtimberford
    ok i just tried switching permissions to 666 for the conf folder and all files inside. no joy. the ownership user and group are the same for all files as well, so it's not that.
  • jacmgrjacmgr
    quote: "Are you not just applying the 777 to the conf folder, but also the php files within it? " Applied to conf folder as well as files in the conf folder (and all permutations). The vanilla set up screens only appear if the conf folder is set less than 777. Really would like to do a frsh install but keep my existing database of users, comments, discussions, but not sure how to do that.
  • MarkMark Vanilla Staff
    @Timberford and jacmgr: What operating systems and versions are your servers? and php? and apache?
  • timberfordtimberford
    edited July 2006
    linux apache: 1.3.36 php: 4.4.2
  • MarkMark Vanilla Staff
    edited July 2006
    What type and version of linux? Debian? Redhat? etc?

    I want to install it on a machine and test.
  • lechlech ✭
    Wow, this is a fairly odd one. I'd like to know if they're still able to modify any other admin sections, primarily globabl application settings, because that could help rule out if it's a permission issue or something smaller.
  • jacmgrjacmgr
    OK. jacmgr has resolved his problem. It has nothing to do with vanilla. Everthing in vanilla was working including other admin processes for themes, categories, languages, etc.... Just extensions not sticking. I noticed I was unable to delete extensions.php even if I changed the permissions to 777 etc.... I tried with ftp and the host cpanel. cpanel filemanager changed the permissions, but the owner was strange and it wouldn't let me delete it and popped a strange error message. So....support ticket to host provider. My hosting provider says that someone hacked into the site a day or 2 before I did my upgrade. The provider didn't give me any more details. The provider reset some ownerships and file permissions. I deleted extensions.php and put a fresh extensions.php and set permissions at 666 or higher and works. (Note that further investigation showed similar isolated file permission problems in other applications on my site due to the hacker)
  • lechlech ✭
    OK, jacmgr, I think I understand what happened there. I want to say that nobody really hacked into the site, but instead when Vanilla created the new conf files within that folder they obviously weren't owned by you and instead by the process which spawned them "apache/php". Hence why you probably couldn't change the permissions or delete them. Not really a bug with either vanilla or the server, just the host has things set up in such a way that files created by the app remain those of the system and not the user/owner.
  • MarkMark Vanilla Staff
    I thought about that too, lech. But if it happened on other files as well as Vanilla files - then it might not be related at all..
  • timberfordtimberford
    im finding out the version of linux. i just changed a few of the global application settings and it worked fine.
  • lechlech ✭
    Mark, do you mean the "unable to delete files" error like described by jacmgr? Because I did notice that on my own install here, while I was still able to rewrite settings the files within /conf/ still belonged to the apache/wheel group instead of me. My guess is that on some setups this can differ where apache will own them, but since it's running under your rights, won't allow you to tweak them. In any case, I simply downloaded a copy, came in as root then toasted the files, replanted them and reset the permissions. I think that the only way to avoid this in the future, is to prepack those files like before and have the user rename/repermission them or find a way to chown them to the correct user via php. I didn't think of this as a big deal before, but since it's cropping up now I'm begining to think otherwise :\
  • jacmgrjacmgr
    My (jaacmgr) issue was a hack and only affected extensions.php file and a few other files. I was doing upgrade form pre-release. Prior to upgrade the hack occurred and changed the owners of a few of the files to some crazy owner id. This was all confirmed by hosting provider. Under normal operations of my host I have no problems with being able to control permissions of any file. It was just strange, how few files were actually affected. (as I said more than just vanilla was affected so nothing to do with vanilla).
  • DinoboffDinoboff
    This line in the trouble shooting is confusing:
    chmod --recursive 666 /path/to/vanilla/conf/
    Apache (or the php user if it is not apache) need access to the directory. The mode to need to be 7 (or 1 or 5 after the creation of the files). 666 is for the files inside conf/
    chmod --recursive 666 /path/to/vanilla/conf/*
This discussion has been closed.