dflorin Posted November 10, 2006 Share Posted November 10, 2006 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. Link to comment Share on other sites More sharing options...
.KX Posted November 10, 2006 Share Posted November 10, 2006 Oh no! Hardcoded words! IT'S THE END AS WE KNOW IT! Oh, they already know about this, anyway. Link to comment Share on other sites More sharing options...
Quillz Posted November 10, 2006 Share Posted November 10, 2006 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? Link to comment Share on other sites More sharing options...
.KX Posted November 10, 2006 Share Posted November 10, 2006 They will fix it with Final, or RC4. Whichever it may be. Link to comment Share on other sites More sharing options...
Will L. Posted November 10, 2006 Share Posted November 10, 2006 They will fix it with Final, or RC4. Whichever it may be.now you are IPS STAFF <_< Link to comment Share on other sites More sharing options...
.KX Posted November 10, 2006 Share Posted November 10, 2006 I am? Oh, wait...really? You're not just tricking me? Do I get payed? I wonder if I have an office... Link to comment Share on other sites More sharing options...
Michael Posted November 10, 2006 Share Posted November 10, 2006 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. Link to comment Share on other sites More sharing options...
WalleniuM Posted November 10, 2006 Share Posted November 10, 2006 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 Link to comment Share on other sites More sharing options...
bfarber Posted November 10, 2006 Share Posted November 10, 2006 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. Link to comment Share on other sites More sharing options...
.KX Posted November 10, 2006 Share Posted November 10, 2006 I thought all files were parsed through index.php, looks like I was wrong. Well thanks for the info. Link to comment Share on other sites More sharing options...
Quillz Posted November 10, 2006 Share Posted November 10, 2006 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: Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.