i find it hard to understand why ips went against all programming good practices and rules and hardcoded some values in the js files for the editor. i am referring to the option panel. if one installs an emoticon that is wider/taller than regular ones (which is a feature), boom, the emoticon box gets scrollbars (it does not resize) and everything gets ugly. we should be able to set the number of emoticons per rox (like 2.1.7) and the width of the emoticon box and editor box- at least in the skin acp. in the end i found those values and modified them for my forum's skin, but it was a white night(mare).

please make them easily editable, as many boards use larger emoticons and will need this. at least define them as variables at the begining of the js file. (skin html would be better, acp settings would be best).

thank you.

Oh no! Hardcoded words! IT'S THE END AS WE KNOW IT! Oh, they already know about this, anyway.

Oh no! Hardcoded words! IT'S THE END AS WE KNOW IT! Oh, they already know about this, anyway.

If they already know of this, then why hasn't anything been done? I agree that the editor, of all things, should not be hard coded and should be easy for it to be edited. I can understand hard coding some parts of source files, but what advantages are there to hard coding portions of the rich text editor?

They will fix it with Final, or RC4. Whichever it may be.

They will fix it with Final, or RC4. Whichever it may be.

now you are IPS STAFF <_<

I am? Oh, wait...really? You're not just tricking me? Do I get payed? I wonder if I have an office...

Getting everything to work is the first priority, removing any hardcoded elements is a lower priority todo item. They totally re-did the editors, there was a lot of work involved just getting them to look right. Maybe you should enter a bug in the bug tracker about this.

i did it some time age... matt said, that the editor "plugins" they wrote don't use any language variables at the moment, because of that its not possible to abstract it (at the moment).- He'll do it for 2.2.1, because there must be made changes which could cause a loose of stability (we are at the RC stage!): I think its ok if he'll do it then and we'll have a stable version 2.2.0

We're at RC3 now, extremely close to a final release of the product.

To fix the 3 or 4 hardcoded language bits, we're going to have to either somehow set javascript variables to define language bits based on a member's selection, or include and instantiate the ipsclass, perform session authentication, and so on to determine a member's selection to pull the language bits in the editor you are referring to.

The specific files with the hardcodes (there are 2, I believe, with 2 language bits in each) are independent php files that do not parse through index.php and do not currently have access to the member's language selection - hence there is no effective way currently to pull a language independent string.

We intend to fix this for 2.2.1 (the first release after 2.2.0) but because we are so close to final, this is going to be too big a change to introduce at this stage to fix such a low-scale issue. :) It will be addressed, just not immediately before a final release.

I thought all files were parsed through index.php, looks like I was wrong. Well thanks for the info.

We're at RC3 now, extremely close to a final release of the product.

To fix the 3 or 4 hardcoded language bits, we're going to have to either somehow set javascript variables to define language bits based on a member's selection, or include and instantiate the ipsclass, perform session authentication, and so on to determine a member's selection to pull the language bits in the editor you are referring to.

The specific files with the hardcodes (there are 2, I believe, with 2 language bits in each) are independent php files that do not parse through index.php and do not currently have access to the member's language selection - hence there is no effective way currently to pull a language independent string.

We intend to fix this for 2.2.1 (the first release after 2.2.0) but because we are so close to final, this is going to be too big a change to introduce at this stage to fix such a low-scale issue. :) It will be addressed, just not immediately before a final release.

Good to hear. :thumbsup: