Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Try Vanilla Forums Cloud product

Ready to contribute?

Amazing! Sign our contributors' agreement and then join us on GitHub.

Update for critical security issue in PHPMailer included in release Vanilla 2.3.1
Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.

Changing text

edited September 2006 in Vanilla 1.0 Help
I'm sure I have seen posts on this before, but I can't seem to find the right thing to search for.

When I installed Vanilla 0.9.2 I modified various bits of text, e.g. the welcome guest message, by searching through the English.php file for the old text and replacing it there and in some other files (e.g. apply.php). I knew it wasn't the best, but I wanted to get started, and I knew it would all change when v1 appeared.

Of course I lost all these changes when I upgraded (just this weekend) to 1.01. So my question is, are there any do's and don't's for making such changes, especially so they'll be retained though any future upgrades?



  • If you want to make changes to the default langauage file, the best thing you can do is probably just copy the file and paste it into a new language directory, and call it English2 (or anything else you like), so when you upgrade your language won't get overwritten. I think (at least so far) when Mark changes the language file, he puts the new stuff at the bottom, so updating your own language shouldn't be too much of a hassle.
  • Actually, with the advent of v1, i believe you can use a conf/english.php file to just include the changes you want to make cant you?
  • edited September 2006
    No, you should make your changes in conf/language.php. But conf/english.php is be a good idea, especially for the LanguageSelector addon.
  • Maybe it should use conf/language for completely global stuff you need to be the same everywhere and conf/english (or whatever) for fine tuning certain language packs...?
  • I'm afraid, as usual, that I don't fully understand.

    Is it correct that the php files in Vanilla generate the HTML code that actual makes up the pages, and that more than one php file can be called on (that's why an extension can work by just being another php file that is called on - e.g. the side panel extension)? And that one php file can over-ride another?

    So are you guys saying that rather than change (say) the file that produces the sign-in message, I can add a new file to the conf folder and it will take precedence over that file?? And why "should" it be conf/language.php and not conf/english.php, and yet the latter still be a good idea? Is there anywhere this is all documented?

    Sorry about all the questions, but I don't know any other way to learn. :)
  • As far as languages and extensions go, i believe, the definition is first loaded from the extension file, then replaced by a definition in the current dictionary if a definition exists, and is then replaced by a definition in the conf/language.php file if a definition exists. Therefore if you want to change something just for your install and dont want it to be overwritten when you upgrade either the forum core or the extension, you should add the definition to your conf/language.php file.

    conf/english.php doesnt actually exist, i just wasnt sure what the custom file was called - then we got onto the topic that perhaps conf/english.php would be more suitable in the case of multilingual forums.

    I hope that helps clear it up a bit.
  • Yep thanks, it does. I'll give it a go.
  • ercatliercatli
    edited September 2006

    That all seems logical, and, looking at the definitions.php and language.php files, I can see how it will all work. This changes the actual text, but retains the overall structure. But if I want to change the structure in some way. e.g. remove the "I agree to the terms" check box at registration (not just change the text), that requires a change to the code - in this case to People.Control.ApplyForm.php. As far as I can see, such changes will be overwritten by updates. I presume the only way to change these so they survive the next update is via an extension??
  • That's correct. Assuming there's one in there you can probably just attach to a delegate in the applyform and make your changes that way. I cant look too closely right now cause i'm at work.
  • Thanks. I don't understand "attach to a delegate", but thanks for the help in increasing my understanding of how php works. I am quite happy to make changes that won't survive an upgrade, keep a note of them, and make them again if necessary. And at least now I can (and already have) make the text changes in the language.php file.
  • As far as attaching to delegates goes, I'd suggest you check out some of the development documentation. I could try explaining but it's 4am and the docs do cover it pretty well. Read through them and come back if you have any questions.
  • 4am! I guess you have to work really hard to be a Lussumo Legend! ;)

    Thanks for pointing me in the right direction. I wasn't expecting you to explain it all to me, and I haven't delved into that part of the documentation yet because I didn't think I was up to it, but I can see I am going to have to find a few good php explanation sites, and read up on controls & delegates etc. And if I understand enough, I'm sure I'll have questions. :)
  • heh. I'd just got in from a night out and figured i might aswell clean this place up before i went to bed. is an excellent resource to get the syntax, purpose, and a couple of examples of a function if you need to look any up, but doesnt (as far as i'm aware) provide any actual tutorials as such. It's worth keeping open in a browser window to just chuck stuff into though.
  • edited September 2006
    About the order, Vanilla read first definitions.php, then conf/language.php and finally the extensions. So a definition in definitions.php will be overwroten by the same in conf/language.php; and one in conf/language.php by the same in an extension.
    Since vanilla 1.0.1, you can avoid overwriting definitions by using $Context->SetDefinition('code', 'definition') to set the definitions for your extensions.
This discussion has been closed.