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.

Global Application Settings

edited July 2005 in Vanilla 1.0 Help

Logged in as admin, I'm trying to set the forum to browsable for users that do not have a membership. Permissions seem fine, the script can write to the appg/settings.php file. Yet it doesn't do anything. In fact, I'm assuming that since all of the fields on this admin page are blank, even if I alter them manually with an editor, there is an issue somewhere that I'm missing.

Thanks! Doug



  • lechlech Chicagoland
    chmod 666 appg/settings.php chmod 666 appg/language.php chmod 666 appg/extensions.php chmod 755 languages/ chmod 757 images/ <- optional</code>
  • That's the first thing I checked but that's not the problem. In fact, I made sure of it because I watched the timestamp on the settings file and I saw that the script had written it out. I think, but I'm not sure, that it has something to do with sessions and the fact I was logged in as admin twice, in two different browsers. ~d

  • lechlech Chicagoland
    Well, I've had times where I have "written" to files but haven't actually WRITTEN to the files. It will say "yeah yeah, I made your changes" but didn't actually write it out so to speak. And you can have multiple sessions open in as many browsers as you want as long as you're logged in, the application doesn't sweat about it. So in short, time stamps really don't mean anything, make sure those files can actually be written to otherwise it's faking the changes.
  • MarkMark Vanilla Staff
    It shouldn't actually fake any changes. It *should* throw an error before making that change. but the failsafe is to open the appg/settings.php file and check the constant.
  • lechlech Chicagoland
    edited July 2005
    well, mark, when I've forgotten to chmod 666 on the settings.php, I was left scratching my head for a bit wondering why some settings didn't take. While it could read the file just fine, it simply faked the save without throwing an error. Then again, you do know I have a totally whack-ass setup. edit:damn im drunk.
  • Trust me, I understand problems with permissions. It's a rookie mistake I don't often make.

    -rw-rw-rw-  1 doug  staff   403 Jul 22 11:51 extensions.php
    -rw-rw-rw-  1 doug  staff   175 Jun 22 14:42 language.php
    -rw-rw-rw-  1 doug  staff  3612 Jul 23 11:45 settings.php

    This symptom of the problem is what really puzzles me: when I load Application Settings from the admin menu, the fields are all blank. No matter how I may have altered them manually in the settings.php file.

    Could the fact that I moved the installation directory at one point have anything to do with it? By the way, I noticed this problem right off the bat, I wanted to change the logo text of course, and ended up having to do it by editing the settings file manually.

    Thanks for your help!

  • lechlech Chicagoland
    Weird. If it's not throwing an error, it must still be trying to write to the old directory location or something. Wait for mark on this one to give his answer. I'd back up the tables and such with an SQLdump and maybe start from a fresh install if there's nothing important on your installation.
  • Very strange indeed. Another anomaly I've noticed: when you view the list of forum categories, then select a category, then start a new discussion, instead of defaulting to the current category from the dropdown, it always defaults to the first one (which in my set-up is also "General"). This bit me a few times as I just assumed (as you should) that, well, you get the idea...

    Thanks for your input Lech.

  • Oops, now the first one here is "Random," anyhoo...

  • lechlech Chicagoland
    Yeah, posting a new thread is nothing out of the ordinary. By default the drop down should be in order with any blocked catagories appearing last. Give or take the minor differences (providing mark isn't on an upgrade riff) everything should look and run along the same lines as your own installation.
  • Okay, I upgraded to .9.2.2 and that seems to have cleared up many of my problems. However, now that I have "Allow non-members to browse the forum" toggled on, once I logout and revisit the forums w/o logging in, Vanilla says "No discussions found."

    I must be missing something, whatever it is I can't seem to find it in the documentation, the Wiki, or by searching this community. You can see for yourself by hitting my Vanilla Forum.


  • lechlech Chicagoland
    Have you toggled each category to be visible by non-member roles?
  • MarkMark Vanilla Staff
    This could be a bug. Want to submit a bug report? Or better yet, add it to the bugs page on the wiki:
  • Lech was onto something there, for sure. I had a feeling I was missing something. I guess this whole role/privilege system was something I needed to understand a little better. It needs to be documented. Sorry to mention that, I'm sure you are well aware of this. Once I get a a bit further along, I'd love to help pitch in and add to the Wiki.

  • Two more things: Can I change my login here to "doug?"

    And the other is: Thank you!

  • lechlech Chicagoland
    Yeah, this is one of those things that apparently got left out of the upgrade notice. As a result, I've just noticed something which I'm attempting to debug and figure out what's going on. You're welcome doug :) Mark, I think I have hit a snag in my genius plan! agh! However, the odd thing is the fact that everything works, but roles have gotten messed up.
  • I found that in order to allow non-members to browse the forums, I had to allow sign-in (if nothing else) privileges for every role for those categories I wanted to be publicly viewable. Now this is fine, but shouldn't I be able to block all access to certain roles, banned for instance?

    Not sure if that's what you are eluding to in your message Lech. ~d

  • lechlech Chicagoland
    edited July 2005

    I've been looking it over, and for the sake of writing this installation wiki I decided to put up yet another DB to go ahead with a fresh install (btw mark, good job on the installer.php, it works for me now :)) anyway, back to what I was originally saying.

    Doing a quick comparison. I noticed 1 thing in There seems to be a slight inconsistancy between roles and categories. For example.

    Go and modify an existing role. You'll notice that it's running the old way, there is no "Select the categories this role should have access to." feature there under can see IP's and other stuff.

    Now go and create a new role. In addition to the default settings, you now have a selector of "Select the categories this role should have access to."

    when you modify an existing category to include a certain role, I think there's some conflict going on or I'm just missing something all together.

    See if this works :

    • In application settings check off : Allow non-members to browse the forum
    • Modify the applicant class(is there still an applicant class to modify?) to browse the forum.
    • Modify the Categories you wish to allow applicants to view.
  • MarkMark Vanilla Staff
    I only added the "select the categories this role should have access to" on the role form when creating a new role. This is because I had a user report a problem where he created a category called "Administrators Only", and blocked access to that category to all roles but admin. then he created a "Moron" role and put one of his friends into it. His friend could see everything in the "Administrators Only" category, so he reported a bug. But it wasn't a bug. The problem was that when a new role was created, it was granted access to all categories by default. So if he wanted the moron role to then be blocked from the "Administrators Only" category, he needed to go edit that category and make sure that Moron was unchecked. So, I was faced with an annoyance in the interface. I decided that the best solution was to keep the "edit a role" the way it is. Because once a role is in place, it's probably better to have all of the category access handled in one place (the category form). But when creating a new role, you need to be aware that the new role needs to have category access limited, so I added that extra bit to the new role form. *inhale*
  • lechlech Chicagoland
    Ok, that makes sense, but wouldn't it make a little more sense if you had to go back and edit that role again for another reason? say you added a couple more categories after that. Then you would need to go back to all those user roles and re-edit those settings. I think my read/write/execute idea is indirectly coming into play here. Why not just pull all the category/role setting out of categories all together. And instead stick what people can and can't see dependant upon their role?
This discussion has been closed.