[ult_combo]

Good thing you've found a reply that better satisfies your question. The problem is most of the bbcode parsing is done through regex, which does not know of recursion nor nesting. This means, to allow for nesting, it'd require either a completely new tokenizer or making more complex regexes and execute each of them multiple times for the wholeness of each post text until no other matches are found, which I've highlighted previously as extremely costly. As you probably noticed, phpBB 3.1.x hasn't been released yet and most likely the devs didn't even think how they will handle it, if they actually still plan to do it. And I'll repeat one more thing. When you write bbcode, you're simply using a simplified markup language that gets translated into HTML. "a" (anchor) elements, also known as links, must not appear as a descendant of the "a" element per W3C spec. Therefore I'll say it in a more notable tone, you'll NEVER EVER FUCKING EVER nest a link inside of another link depending on my part. Sure thing we could add extra parsing rules to end a link when a nested one starts then resume the initial one after the nested ends, however it is more than obvious that no one in the right mind will spend time and server resources just so lazy bastards can write illegal markup. 'nuff said. Also thanks Crescent for highlighting that.

[Crescent]

Please once again note that this has absolutely nothing to do with bbcode or phpbb. You cannot do this in pure HTML or any other language. Anything between two tags has the capabilities set from the starting to the ending tag. The fact that it sometimes works as you would expect when you incorrectly use them does not change the fact that you are using them incorrectly and will produce varrying results. Apart from that, you seem to have already expected an answer. I can unfortunately just repeat what was already said. One should not break the rules of a language like that.

[jacxxx]

Original question jacxxx: Q: why was it again that nesting is not supported? Security?? I think a short and honest answer should be something like Some BBCode nesting is not possible with the current parser. The BBCode parser in 3.1.x will be much better at handling nested BBCode. Short explanation for those of you who sometimes use the buttons in edit mode: A simple user like me never types in cumbersome square bracketed tags like e.g. [c=1]w1 w2 w3[/c] (with c=color) but instead I will type a text, select the part of the text that should get color 1 (the three words w1 w2 w3) and then click the corresponding "Font colour: ...." option in the edit mode. Checking the result in the Preview screen most of the time shows the result as I want it. However, when I give the word w2 color 2 using the same method, Preview doesn't show what I mean. The code generated is quite alright: [c=1]w1 [c=2]w2[/c] w3[/c] unambiguously describes what I want: w2 should have color 2, w1 and w3 color 1. Only programmers seem to think for a moment that w2 should have two colors at the same time, but of course that's not what the simple user, nor the phpBB programmer who built the edit-buttons have in mind. Unfortunately the phpBB programmer who built the Preview etc did a bad job, we must manually adjust the code: [c=1]w1 [c=2]w2[/c] w3[/c] --> [c=1]w1[/c] [c=2]w2[/c] [c=1]w3[/c]. It's not a bug, maybe not even an error, it's just something the user doesn't want. Exactly the same occurs when using the URL button: [u=1]w1 [u=2]w2[/u] w3[/u] (with u=URL) again describes unambiguously what I want: when you click w2 you should be sent to url 2, clicking w1 or w3 you should be sent to url 1. Again we have to manually add [u=1]w1 [u=2]w2[/u] w3[/u] --> [u=1]w1[/u] [u=2]w2[/u] [u=1]w3[/u]. In my original post I wanted to find&replace a word w2 --> [u=2][c=2]w2[/c][/u] in a long index and discovered in a test-post again the peculiarity that the resulting code is not parsed as it should be. This replacement occurs about 60 times for w2, and there are many more words --> too much to manually adjust it. That's why I asked my simple question again.

[ult_combo]

jacxxx: Since to me "url in url ... " looks similar to "spoiler in spoiler in ... " "Similar"? Similar as in both starting tags beginning with "[" and ending with "]", while being closed by the same tag with a "/" before the tag name? Sure, this is the only similar aspect because it is the phpbb's standard tag syntax. What you're missing is that all similarity ends there, as these 2 tags have completely different functionalities, and as such their specific rules (such as allowed values and nesting) will differ. Every time you use a bbcode tag, phpbb will apply an html template to it (assuming that the provided input is valid), rendering your text into actual markup that will be functional when a browser receives it. Nesting spoilers makes sense - they are independent and their toggle functionality works fine inside of another spoiler. Putting a link inside of a link, in the other hand, makes absolutely no sense and is illegal markup. What do you think a browser would do in such case? (rhetorical question). A link can only point to one single URL, by putting a link inside of a link the browser would most likely attempt to open both links at once, if that wasn't illegal. As the spec doesn't allow that, browsers would fail to render the links correctly and try to recover them the "best" way possible as they saw fit. This erroneous behaviour should never happen though, and as such our backend will never allow "nesting links". As for nesting repeated styling properties, it is a little more tricky. Even though it'd be valid markup, it is simply not valid phpbb code. The phpbb devs chose it to be this way. That's because there's absolutely no gain for nesting the same property (see Sat's post above - simply close it and open a new one, that is much concise and clear) and providing the ability to nest EVERY tag would be extremely costly in terms of backend processing - and as already mentioned, unnecessary. If you still remember the thread about spoilers, you will remember that the spoilers nesting ability has been added to the current software by me. That means I've rewrote the spoiler parsing from the ground to allow for that. There are other parsing rules that have been changed/rewritten to improve security and fix some bugs. As you see, we will not edit the parsing rules unless it is to add useful new features/functionalities or fix security issues. Changing topics, as Sat implied with "please stop making stuff up", he actually means that. You have over 270% of the minimum likeliness to be banned, you should know that already as you alone gave more trouble to the mods than every other user. Could say it is a miracle you're not banned yet - most likely because I've spent a good part of the time that I could be making new features to personally reply many of your questions. We value users that have been around for so long, and your contributions. I'm also thankful to your speed for finding actual bugs and contacting us (e.g. that time when the new viewtopic table layout was breaking with polls present). However, if you keep attempting on our patience, your account may not last one week more at this rate. I've attached a graph of current projects development from the LAHWGs I'm in, private projects (non-public projects that haven't been confirmed or announced) are codenamed to a single letter without details for brevity. The detailed ones should be enough to give you an idea of what I'm talking about though. Order of importance is grouped by project name's font size. I've doubled your name's font-size otherwise it wouldn't be readable in the screenshot.

[Sat]

You are basically trying to cross two tags into each other. That is an illegal action in almost all tag languages that exist. Why not just go step by step, link Mio to one link and the rest of the text to the rest? Mio starts to feel more relaxed. Misaki tries to help her. Code: [list=1] [*][url=http://lah.li/forum/viewtopic.php?p=283367#283367][color=#3F5168]Mio[/color][/url] [url=http://littleangelshentai.net/forum/viewtopic.php?p=265057#265057]starts to feel more relaxed. Misaki tries to help her.[/url] [/list] As I said, crossing tags or commands is very illogical towards the very nature of programming. Everything has to be clearly defined. This is not a bug, please stop making stuff up.

[jacxxx]

Sat: What you are trying to do is not nesting, it is crossing. What do you mean by "crossing"? Sat: ... note that this is a test post thread and not your sandbox. This forum is called "Help and test-post forum" and in my previous post I asked for help about a test post. Since to me "url in url ... " looks similar to "spoiler in spoiler in ... ", "color in color in ..." and "bold in bold in ..." I chose this thread. If you like I can start a new thread (my own sandbox) about this subject, with the same help question and the same test post

[Sat]

What you are trying to do is not nesting, it is crossing. This is not only not supported in bbcode, but neither it is in any markup language, including HTML. Also please note that this is still a test post thread and not your sandbox.

[jacxxx]

ult_combo: Our forum system doesn't support sub-spoilers. Btw you can also check how the BBCode tags will behave from the preview button. I think it doesn't work because our current PHP BBCode filters/doesn't accept opening a repeated BBCode tag without closing it first. (example code below) Code: [spoiler][spoiler]test[/spoiler][/spoiler] [b][b]test[/b][/b] [color=red][color=white]test[/color][/color] Will show as: test [b]test[/b] [color=white]test[/color] In other words, you can't open a spoiler inside another spoiler because our current PHP BBCode software automatically filters repeated unclosed tags. Maybe Sat could take a look at that when implementing LAH's next PHP BBCode and add an exception for the spoiler tag? Not that it is *EXTREMELY* needed, but it comes in handy in quite a few situations for maintaining long threads/posts organized. I just ran across the following problem: in the Mystics Index - which I made in cooperation with Arrancar - I have to change every word "Mio" by "Mio " and similar for other characters in Ar's Mystics Saga. Of course this is easily done after copying the content into MSword, find and replace Code: "Mio" by "[color=#3F5168]Mio [/color]" etcetera. Mio also has a profile, so I thought: why not find and replace at once Code: "Mio" by "[url=http://lah.li/forum/viewtopic.php?p=283367#283367][color=#3F5168]Mio[/color] [/url]" Well, "Mio" occurs only within url's, e.g. in this list item: Mio starts to feel more relaxed. Misaki tries to help her. replacing "Mio" by "Mio " (<-- with URL!) we get: [url=http://littleangelshentai.net/forum/viewtopic.php?p=265057#265057] Mio starts to feel more relaxed. Misaki tries to help her. [/url] In short, using a small extension of Ult's examples: Code: [spoiler]in [spoiler]test[/spoiler] out[/spoiler] [b]in [b]test[/b] out[/b] [color=red]in [color=white]test[/color] out[/color] [url=http://lah.li/forum/viewtopic.php?p=269334#269334]in [url=http://lah.li/forum/viewtopic.php?p=269334#269334]test[/url] out[/url] we get: in test out in [b]test out[/b] in [color=white]test out[/color] [url=http://lah.li/forum/viewtopic.php?p=269334#269334]in test out[/url] Adding "in " in the spoiler we see only the spoiler works, the rest doesn't - as was to be expected. Q: why was it again that nesting is not supported? Security?? Wanted: allow a reasonable depth of nesting for every reasonable option, why not

[jacxxx]

In the present guinea pigs stage I couldn't post screens 1, 2, 3 below discussed in this announcements post

[ult_combo]

Oh yes, the next guinea pigs stage begins sooooooooooon enough. Well, not really, as only the end-user interface is half-complete, but I'm sure you'll enjoy testing it once it's released.

[jacxxx]

It's clearly a well prepared update, Ult, as a first part in the process of bringing the LAH software to the next level(s). I would like to be a guinea piggy again soon and test some of these new levels

[ult_combo]

Yes, even though all additions are tested throughout, our small Quality Assurance team (just Sat and me for that project) is unable to test every possible case. So instead, we focus in making sure that it leaves no security breaches which could expose our users to malware and that there are no issues that could break/conflict with other parts of the system. After the addon is judged safe and working, it's then implemented. As we have 100~150 active users during all times of the day, one hour of the implementation live in the server is equivalent to 6 days of Sat's or my testing. This is undoubtedly when users will find small bugs and report them to be fixed. As the addon has been already tested against virtually all exploits and is dimmed safe, user testing is extremely effective as shown by the number comparison above. One may say that users are used as "guinea pigs" in this case. That was just an overview of how the QA and implementation part goes, but in fact, for this implementation, the line breaks' behavior was Status by Design¹. The initial implementation had line breaks dimmed as illegal as many exploits require line breaks in them to work. Obviously, there are already measures to prevent those exploits in place. Hence the line breaks exception was just an extra unneeded layer of security which changed the behavior of [url] and [magnet] tags slightly. I coded it there as an extra layer of security, but it was removed as it's unnecessary and the new code now behaves much more closely to the original system. ¹Status by Design: Indicates that the bug/feature/observation it is attached to is intentional.

[jacxxx]

ult_combo: Apparently, the new security didn't like your link descriptions with line breaks inside of them. I quickly accommodated for that. --> thanks very much for that, leaving the line break to the software often gives undesirable results! ... the new url/magnet ... is much more safer, ... and makes use of an advanced blacklisting feature (100% ©Ult_Combo) providing a much higher control of what can and cannot be linked. --> splendid The change shouldn't be very noticeable to the end-users, as it's mostly just internal security. Also, as a side note: On your next lists, you may as well try putting the links inside of the list items --> ok! It seems you also sent this post directly from mind to mind, Ult! This post [Wed Jul 11, 2012 8:17 am] crossed my last edit edit2 [Wed Jul 11, 2012 8:16 am] which I ended with "it was my first thought and I still can't rule it out: an unsuccessful software change trial by Sat and Ult ..." But instead of "unsuccessful" I should apparently have written "successful"

[ult_combo]

jacxxx: The problem has disappeared now. I didn't have clickable links, just URL-codes; the list numbers did appear however as they should in preview. That all happened in chrome yesterday as well as in opera this morning. But as I said, everything now suddenly works again ... Yeah, Sat passed me the feedback alongside a sample of the faulty scenario after my post here. jacxxx: edit: I'm now trying to reconstruct what I did yesterday, ... I guess that won't be much of use as the issue was server-side. jacxxx: It looks as if only some lists with links to Ar have been influenced around last Monday. A dedicated hacker who ran away by this alert? Idk! I wouldn't worry that much. Thing is, Sat finished reviewing a HUGE security update which I submitted 2 months and half ago and it was just implemented yesterday. Apparently, the new security didn't like your link descriptions with line breaks inside of them. I quickly accommodated for that. I guess Sat wouldn't like me opening up too much of the new url/magnet specs, but now it is much more safer, fixed many bugs and possible exploits, it now allows a wider range of characters and makes use of an advanced blacklisting feature (100% ©Ult_Combo) providing a much higher control of what can and cannot be linked. The change shouldn't be very noticeable to the end-users, as it's mostly just internal security. Also, as a side note: On your next lists, you may as well try putting the links inside of the list items: Code: [*][url=address]description[/url] Some of your lists are in this format: Code: [url=address][*]description[/url] Which generates technically illegal markup, but our systems currently take care of accommodating it. Writing your future lists in the correct (first) manner might save you some trouble in the future though.

[jacxxx]

ult_combo: Just tested all links on your post jacxxx, they are working as intended in Opera 12 (the browser you're using atm, right?). What's the problem with the links there? You can't click them? They go 404 (not found)? They redirect to another page? If you have any screenshot or info you'd judge useful, submit it and we will take a look. The problem has disappeared now. I didn't have clickable links, just URL-codes; the list numbers did appear however as they should in preview. That all happened in chrome yesterday as well as in opera this morning. But as I said, everything now suddenly works again ... edit: I'm now trying to reconstruct what I did yesterday, behind the same PC with Chrome. On this PC I clear my history at the end, so I can use only my own memory now. I opened this post to edit it, and to reuse it for an index of another of Arancar's chapters. Right now I see ìt is "Last edited by jacxxx on Mon Jul 09, 2012 9:03 pm; edited 10 times in total". Perhaps the time is incorrect, I edited it last night, and it looks I didn't save the last edit (a.o. move the title to the text). So I do this now - preview this time doesn't show any problem, as it did last night - to check which date/time it will give ... It now gives "Last edited by jacxxx on Tue Jul 10, 2012 6:05 pm; edited 11 times in total" That's just one hour too early. Seeing yesterday that in my preview the white colored url-codes were visible before and after the list numbers - without showing any field which could be clicked (in fact: the url's looked exactly the same as in the edit mode, but the list numbers showed up as they should in preview), I looked at similar lists: this one and this one showed the same problem - also changing the place of [*] didn't matter. I thought I had saved such a change in one of them, but after all perhaps it was only in preview. They appear to have only been edited once to insert the index. Yesterday I also checked this old one - without list - and it still was ok. Then I quit the Arrancar works until this morning, when I made up the previous post. After posting the first part of the present post I checked a private message sent Sun Jul 08, 2012 11:57 pm to Arrancar and containing the list in the attachment, it showed up correct this morning! It looks as if only some lists with links to Ar have been influenced around last Monday. A dedicated hacker who ran away by this alert? Idk! edit2 Wed Jul 11, 2012 8:16 am: in case it would happen again, I have overlooked this index until now. Everything's still working fine, it seems ... I wonder what has been the cause. Most likely - it was my first thought and I still can't rule it out: an unsuccessful software change trial by Sat and Ult ...