Support for [ and ] and a few other bug/problems fixes.
| Project: | Table of Contents |
| Version: | 6.x-3.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | AlexisWilke |
| Status: | closed |
Jump to:
Hi deviantintegral,
I like this module! Really cool!
Now, I have a long one here, most of which is fixed in the attached patch. 8-)
1. WYSIWYG problem
Solution
Now, I have one major complaint... I use a WYSIWYG editor and writing a comment is a real pain and it can be real slow too (because I need to switch between WYSIWIG and Source). But my main concern would be to explain to my customer (really totally end users) to write an HTML comment. Just forget it!
So I would really appreciate if you would apply my patch to support both: the comment and [tableofcontents...]. That would really rock and I'd bet a lot more people would start using your module like crazy (note that I did not invent the syntax, all the other filters I've seen so far make use of the square brackets.)
Another personal note: it is a lot easier to write [ and ] rather than <!-- and -->... 8-) [got to find good arguments, right?]
Potential Problems
Patch wise, the functionality is complete, but the help was not changed. If you accept this, then I will be happy to fix the help too. 8-)
Also, because I use my WYSIWYG editor:
- The table finds itself inside a paragraph (<p>). I'm not too sure, but I think lists cannot be inside paragraphs.
- By default, the Teaser is the [tableofcontents ...] tag and nothing else.
Again, I will be glad to look into fixing these problems if you accept the use of that syntax.
2. Search Pattern
Invalid use of period
Your search pattern uses (.*) within the comment. The problem is if you write two comments one after another, you will pickup both. Of course, an easy fix is to add a newline. But imagine two filters used back to back and the person does not want a newline...
The period (.) should be something like [^>] instead (anything but a closing angle bracket).
Invalid use of question mark (partial patch)
This one, I think you should also fix: the comment starts with <\!-- ?tableofcontents... I think that the question mark ought to be an asterisk. That way if someone puts two spaces it still works.
Similarly, the option name and value are separated with nothing or one single space. (i.e. ': ?' -> ': *').
Missing ';' at the end breaks everything
It would be neat to add a ';' if missing at the end of the string.
3. min/max problems
The maxlevel improper use (no patch)
There is a case that you do not handle properly. I have a partial fix for it, but it could be a lot better.
Say I write this: <!--tableofcontents minlevel:4>
(with my fix for the ending semi-colon, it works 9-) )
Now you have the default maxlevel set to 3 and the minlevel set to 4. You then have a test that says: if max is smaller than min, blame the user (he! he!). I think that if the user sets minlevel to 4, then maxlevel should be set to at least 4.
To do that, if you consider this a bug, you should set maxlevel to something like -1. If it is still -1 after parsing all the user options, get the default from the variable and if smaller than minlevel, set it to minlevel.
I'll provide a patch if you want.
The maxlevel invalid reset
The next problem with the maxlevel is that you set it to 3 if it is smaller than minlevel.
And if I just put minlevel to 4, setting maxlevel to 3 is bad. 8-)
Also the error message is wrong, since it mentions 3.
Error messages
Small mistake, the maximum may have been bumped by 1 at some point. The maximum minlevel should be 5 (although, 6 should work too, but that's okay) and the maximum maxlevel should be 6. At this time, these are 4 and 5 respectively.
4. Optimization
Outside of the fact that the theme function could be in a .admin.inc file, I think that the css & js can be added only when necessary. I would think that I'm affected by the cache and I did not see any difference between your way of putting the loads in the _init() function and the case 'process': just and only when a table is generated. This would be a lot better since 99% of my pages do not have a table of content and creating special Input Formats as an optimization is not very effective (especially for end users who have no clue.)
This appears in my patch, but please, make sure it works in all cases! I'm not 100% sure that my cache is being used.
Okay! That's it for this time. 8-)
Thank you for your time and patience with that one!
Alexis Wilke
| Attachment | Size |
|---|---|
| tableofcontents-6.x-tag-n-more.patch | 7.29 KB |

#1
Thanks for the patch / review / etc.
1) The reason I used HTML comment syntax was for two reasons. First, I wanted it to be the same as Drupal core, which uses
<!--break-->to indicate where a teaser is. Also, I wanted users to be able to disable the module and not have their pages littered with unfiltered TOC tags.I'm open to making it a configurable option - could you re-roll the feature so that the filter settings page has radio buttons to select between the two options? I think supporting both styles on a single site is a bit of a support nightmare. Also, make sure the help text indicates that the HTML comment style option will be hidden if the module is disabled, as I could see really "new" users not knowing about HTML comments.
For the WYSIWYG editor... the real way to fix this is to do a button pluging for TinyMCE / FCKEditor / WYSYWIG api / etc. This is something I've been meaning to do but haven't done yet :). For TinyMCE, there is a "drupalbreak" plugin which should be easy to modify to act as a button for inserting a table of contents. This should then fix the paragraph tag issue.
2) Good catches on the regular expressions. Those changes all make sense to me.
3) Yeah, always good to do things automatically if possible, rather than throwing an error!
4) I ended up opening a whole can of worms when I enabled caching for this module. Before that was done, CSS and JS were only loaded when the filter was run, which worked fine. The problem now is that the module code isn't called at all on cached results. We can't even rely on hook_nodeapi as the filter could be used in a block or comment.
Assuming the site has CSS and JS aggregation turned on, I don't think there's much of a performance impact by including them on every page. My (quick) testing with YSlow showed virtually no difference in page performance, even without aggregation enabled.
I really want to get a new version tagged soon, so for #2 and #3, can you open new issues with appropriate patches? Then those fixes can get in to 2.3. For #1, re-roll in this issue if you can, but as it's a farily significant change, I'd like to save it for the next version (there's lots of changes in -dev all ready which really need to go out). And for #4, if you have any optimizations which work with caching enabled, please post in a new issue, but unless they're really simple lets save them for 2.4.
Sounds good?
Thanks,
--Andrew
#2
Alexis, someone all ready started work on making the start / close characters a setting. The issue is over at #326742: Make the Token a setting, so you may want to look at that code too.
#3
Wow! That was back in October!
Thank you for pointing it out. It looks like what I should use instead of hard coding comment or brackets.
There should probably be a default function to get the default and show that if the user does not define his own tag.
I will do some work on that soon. Got to fix a few other things right now 8-)
Thank you.
Alexis Wilke
#4
The default should be provided in every instance of
variable_get. Something likevariable_get('tableofcontents_start_token_' . $format, "<!--");should do the trick.#5
FYI #353298: TOC in div with id? will affect just about anything with regexes.
#6
deviantintegral,
Cool, actually that means I can use [tableofcontents-toc] and not worry about my other fix. 8-)
Thank you for doing it yourself (he! he!).
I will get back to the other things mentioned here though.
Alexis Wilke
#7
Glad that works for you - an entirely unintended side effect!
#8
Fixed in 3.x-dev.
Thank you
Alexis Wilke
#9
Automatically closed -- issue fixed for 2 weeks with no activity.