[Pushed] SCeditor font face
#11
I just "SAID" that above and you started abusing your shift for no reason.. I don't know what exactly surprised you when a developer expected a more detailed bug report from you, which will actually help the team with fixing it later for free for you and other admins. The sticky thread also states what's expected: http://community.mybb.com/thread-133629.html
(2013-01-28, 01:58 AM)Paul H. Wrote:
  • Please show exactly how you encountered the bug, using screenshots if possible
All you've shown us was text on white background (could be screenshoted anywhere) and a SCEditor reference which was wrong, since as you said yourself it works fine in WYSIWYG mode, the only place where it could've been bugged in SCEditor. If you're not fully acquainted with WYSIWYG editors' functionality, which are "live" dynamic editors rather than static parsers used to analyze/convert stuff so that it can be displayed in a readable format, it's better to show the issue directly instead of providing misleading information.

But now that you provided necessary information (direct link which I kindly requested above - thank you), I can confirm it and it's caused by this change: https://github.com/mybb/mybb/commit/add8...34733cR661 since that character is inserted in the tag, which breaks the parser. The regex also catches font=. I'm not sure why I can't reproduce it locally/here though, I'll check whether it depends on some parser options.
Reply
#12
(2016-03-14, 06:57 AM)Destroy666 Wrote: I just "SAID" that above and you started abusing your shift for no reason.. I don't know what exactly surprised you when a developer expected a more detailed bug report from you, which will actually help the team with fixing it later for free for you and other admins. The sticky thread also states what's expected: http://community.mybb.com/thread-133629.html
(2013-01-28, 01:58 AM)Paul H. Wrote:
  • Please show exactly how you encountered the bug, using screenshots if possible
All you've shown us was text on white background (could be screenshoted anywhere) and a SCEditor reference which was wrong, since as you said yourself it works fine in WYSIWYG mode, the only place where it could've been bugged in SCEditor. If you're not fully acquainted with WYSIWYG editors' functionality, which are "live" dynamic editors rather than static parsers used to analyze/convert stuff so that it can be displayed in a readable format, it's better to show the issue directly instead of providing misleading information.

But now that you provided necessary information (direct link which I kindly requested above - thank you), I can confirm it and it's caused by this change: https://github.com/mybb/mybb/commit/add8...34733cR661 since that character is inserted in the tag, which breaks the parser. The regex also catches font=. I'm not sure why I can't reproduce it locally/here though, I'll check whether it depends on some parser options.

I noticed the same problem after upgrading to 1.8.7. Is there allready a solution for this problem?
Reply
#13
You can temporarily revert the mentioned change. There were some thoughts about releasing a patch to the 1.8.7 release, but I doubt it'll happen.
Reply
#14
(2016-03-17, 06:39 PM)Destroy666 Wrote: You can temporarily revert the mentioned change. There were some thoughts about releasing a patch to the 1.8.7 release, but I doubt it'll happen.

I'm sorry but I'm a beginner concerning this kind of scripts. But I'm learning every day Wink

Do you say that I have to replace the inc/class_parser.php  with the previous one from version 1.8.6?

If I do so, there should not appear some other problems?
Reply
#15
You can just replace the line I linked (yellow) with red lines above it. Or add \s before on in the current regex.
Reply
#16
(2016-03-18, 08:16 AM)Destroy666 Wrote: You can just replace the line I linked (yellow) with red lines above it. Or add \s before on in the current regex.

I'm very sorry but I don't understand this. Wich link do you mean?
And what do you meen by "Or add \s before on in the current regex."?

Is changing the whole file also a save option?
Reply
#17
Deleting this line from in/class_parser.php worked for me.

"#(on)([a-z]+\s?=)#i",
Reply
#18
(2016-03-25, 04:15 PM)Spizy Wrote: Deleting this line from in/class_parser.php worked for me.

"#(on)([a-z]+\s?=)#i",
and is a very bad idea, because deleting this line enables a really huge XSS vulnerability ^^
You found my signature? Well done : - )
Reply
#19
This will be fixed in the incoming quick patch, so marking as Pushed.
Reply
#20
(2016-03-25, 06:25 PM)Destroy666 Wrote: This will be fixed in the incoming quick patch, so marking as Pushed.

Is there at github (somewhere) a pr/commit where it is fixed till there is some update?

Because your proposed change didn't work - still getting [ font ] through the quick reply Sad


https://github.com/mybb/mybb/commit/c7a8...34733cL661  Rolleyes


but still didn't fixed it - I can paste preformated stuff at the quickreply/normal post and I get [ font ] everywhere
Reply


Forum Jump:


Users browsing this thread: 5 Guest(s)