New event plugin: Table of Contents for Articles

[bugrep]

but back to my initial posting regarding entrysplit.
even after an entry is saved in the database, one can reach pages where this warning is shown.
e.g. via the archive or calender sidebar
such as http://blog.0wnz.at/index.php?/archives/2009/01.html

---

similar bug in the category_dhtml_menu sidebar plugin where $categories is empty in line 120+, if there are no categories.

[garvinhicking]

Hi!

Okay, for safety I patched the plugins to no longer emit that warning. Thanks for mentioning!

I was quite surprised to see that PHP had dropped $HTTP_*_VARS. I believe this is a huge problem with many PHP applications, for no apparent reason.

Regards,
Garvin

[bugrep]

no idea, im not following the development of php.
i gathered that fpdf does not use the old style since its v1.53 (2004-12-31).
i have that version installed as a debian package. so why did this bite me?
guess the s9y plugin supplies its own fpdf code?

-------

next problem... freetag styling.
the background (and border) of the taglist does not match die background of the rest of the blog.
im refering to the box with related tags, that is shown, when you click on a tag and all articles with that tag are shown. i dunno if this styling is used somwhere else.

it is defined in serendipity_event_freetag.php

Code: Select all

 1968 .serendipity_freetag_taglist
 1969 {
 1970     margin: 10px;
 1971     border: 1px solid #' . $this->get_config('flash_tag_color', 'ffffff') . ';
 1972     padding: 5px;
 1973     background-color: #' . $this->get_config('flash_bg_color', 'ffffff') . ';
 1974     text-align: justify;
 1975 }

the default value is white (not only the fallback(?), seen above, but the default when it is installed). im using the mt-trendy template, which uses a dark gray background.

i disabled the flash tag cloud (or it was the default), but since the name in the config is "Flash tag cloud background color" etc. i thought it is not used for the background and forgot that this option even existed :)

and.. even more puzzeling... there is an event plugin and a sidebar plugin. both have those flash color options, but i think the sidebar plugin does not use the background color?

the color of the title font in the "Related tags" box uses selector ".serendipity_freetag_taglist", which does not define a color.
so it inherits from body. this is probably right, but than the default color in mt-trendy should be changed to match all the rest (#cccccc)? this would make a lot of "color" attributes in the template style obsolete, they could be inherited.
i dunno why this is not done, there are a lot of other occurences, where there is no distinct color set and "black" is inherited. and they all look bad.
namely "No Trackbacks", comment form explanations etc.

so..
1. please change the naming of the freetag plugin options, they are misleading atm. took its time to figure this all out :)
2. changing the mt-trendy/style.css/body/color declaration to #cccccc works fine for me and should be patched that way in the distribution imho.
3. the font color and border color of the tag clouds use the same option. they are always the same (not a problem for me/in in the "mt-trendy" template).
4. maybe the plugin should use other defaults for the colors?
the values in .serendipity_title and .serendipity_entry are responsible for the border colors of the boxes with the entries underneath the "related tags" box.
i dunno how to reference them within the freetag css or if this is even possible, but maybe the php could read it out? they would be my choice for default border colors.
for the background color of the taglist... it is nice that one can configure it, but more important (to me) would be, that the default matches the blog. so either taking the default value from the css of the body or just not set it at all and let it inherit from the parent.
hm.. adding an option to the plugin "override default colors" or something would provide both possibilities. what do you think about that?
i probably could hack that in, but id prefer not to (my youngest php code is about 7 years old... :)
5. serendipity_event_freetag/lang_en.inc.php:54:@define('PLUGIN_EVENT_FREETAG_USE_FLASH', 'Use Flash to display the tag cloug?');
6. google search plugin
the text field is not limited in size. the text field of the internal quicksearch is.
if you use both in the side bar, they are not aligned to each others.
adding size="13" in serendipity_plugin_google_quicksearch.php:161
echo '<input type="text" name="q" maxlength="255" value="" />';
fixes this.
---
another small thing i want to provide some feedback on:
in the freetag todo list i read:

* - Remove comma-delimiting and use the 'standard' space delimiting instead
* - - convert tags with spaces to no-space tags

not using the simple (read: dumb) standard tags is a feature for me.
dunno the implications on search engines, rss readers etc. but i really don't understand why they started banning spaces in tags in first place. as long as they are case sensitive (for CamelCase formatting) this change would be ok for me, but i dont see an advantage in removing the possibility of using spaces.
it is work. it takes away freedom.

hope you preceive this posting as positive critic and not someone moaning around. i tend to sound grouchy, dunno if thats true in writing too :)
and sorry for the length.

[garvinhicking]

Hi!

no idea, im not following the development of php.
i gathered that fpdf does not use the old style since its v1.53 (2004-12-31).
i have that version installed as a debian package. so why did this bite me?
guess the s9y plugin supplies its own fpdf code?

Yes, the plugin supplies its own fpds code to have no dependencies. I've upgraded the bundled version to 1.6 now, though.

next problem... freetag styling.

I've changed the plugin to not use that CSS when flash is disabled, thanks for mentioning.

As for mt-trendy: This is a movable type port, so we only used the CSS that was in the original design. I've committed your change because this sounds reasonable.

3. the font color and border color of the tag clouds use the same option. they are always the same (not a problem for me/in in the "mt-trendy" template).

What do you mean? The .serendipity_freetag_taglist only uses border and background-color, which has two different config names?

4. maybe the plugin should use other defaults for the colors?

The default color suits most of the s9y names with a bright color...

the values in .serendipity_title and .serendipity_entry are responsible for the border colors of the boxes with the entries underneath the "related tags" box.
i dunno how to reference them within the freetag css or if this is even possible, but maybe the php could read it out? they would be my choice for default border colors.

You can actually change all the coloring in the style.css file of your mt-trendy version - it's not suggestable to do this inside the PHP code. Once your CSS file uses a ".serendipity_freeTag" declaration, the plugin does not output any custom styling.

for the background color of the taglist... it is nice that one can configure it, but more important (to me) would be, that the default matches the blog. so either taking the default value from the css of the body or just not set it at all and let it inherit from the parent.

You can't really parse, what the color of a template is, because the specific CSS is impossible to interpret in PHP scope. You'd have to emulate a complete CSS-compliant device parser to deduce the actual color. If you want to use a matching styling in the template, your CSS of the template could style it easily.

hope you preceive this posting as positive critic and not someone moaning around. i tend to sound grouchy, dunno if thats true in writing too
and sorry for the length.

Nono, many thanks. I'm just in a hurry, so I hope you don't mind I shortened it

Regards,
Garvin

[bugrep]

I've changed the plugin to not use that CSS when flash is disabled, thanks for mentioning.

i applied these changes and they do ok. the border is gone, but thats better anyway i think :)

3. the font color and border color of the tag clouds use the same option. they are always the same (not a problem for me/in in the "mt-trendy" template).

What do you mean? The .serendipity_freetag_taglist only uses border and background-color, which has two different config names?

i meant that the font color is set by flash_tag_color somwhere... but that was a mistake i think... anyway thats obsolete now. :)

4. maybe the plugin should use other defaults for the colors?

The default color suits most of the s9y names with a bright color...

sure, i was not proposing another hardcoded value ;)

You can actually change all the coloring in the style.css file of your mt-trendy version - it's not suggestable to do this inside the PHP code. Once your CSS file uses a ".serendipity_freeTag" declaration, the plugin does not output any custom styling.

for the background color of the taglist... it is nice that one can configure it, but more important (to me) would be, that the default matches the blog. so either taking the default value from the css of the body or just not set it at all and let it inherit from the parent.

hm so your suggesting, that the template style.css should override the default style of the freetag plugin, did i get that right?
thats of course easier, than parsing and interpreting the css :)
but why do they need a default style anyway?
wouldnt it be better, if they just inherit their defaults from the template as i tried to ask in my last posting? :)
$long_pause$
oh, you did exactly that, by patching out the declaration. heh

did you see 5. and 6.? i made this edits in the morning, maybe even after you have replied, sorry for that.

[garvinhicking]

Hi!

hm so your suggesting, that the template style.css should override the default style of the freetag plugin, did i get that right?
thats of course easier, than parsing and interpreting the css
but why do they need a default style anyway?

That's right, yes. They need a default style, because there are s9y styles in use that do not look properly because their inheritance is not properly set, just like mt-trendy.

did you see 5. and 6.? i made this edits in the morning, maybe even after you have replied, sorry for that.

Ah, editing is pure evil. I never watch that, making a new posting is always much better.

I've fixed #5 and #6.

Regards,
Garvin

[bugrep]

next i patched the way the tags are displayed in the sidebar:
the title of the links (popups) did already contain the entry count with that tag, but the actual link did not. dont know if you wanna include that, but it was a trivial hack, even for me

Code: Select all

583             $html .= '<a rel="tag" href="' . $taglink . serendipity_event_freetag::makeURLTag($name) . '" title="' . htmlspecialchars($name) . ($quantity > 0 ? ' (' . $quantity . ') ' : '') . '">' . str_replace(' ',' ',htmlspecialchars($name)) . '</a>';

to

Code: Select all

582:            $quantpar = ($quantity > 0 ? ' (' . $quantity . ') ' : '');
583:            $html .= '<a rel="tag" href="' . $taglink . serendipity_event_freetag::makeURLTag($name) . '" title="' . htmlspecialchars($name) . $quantpar . '">' . str_replace(' ',' ',htmlspecialchars($name)) . $quantpar . '</a>';

then i noticed, that the sidebar dimensions are somewhat fixed(?), causing the "( $quantitiy )" elements of the longer tags to be in there own line.
so i changed the sidebar style to "white-space: nowrap;" as you suggested in http://board.s9y.org/viewtopic.php?p=5113#p5113
worked nicely... only that now the +/- elements of the sidebarhider were pushed to their own line.
the sidebar plugin provides an option to set the style of those hider elements, which gets saved in the database correctly and produces a css declaration named "serendipitySideBarLink" (serendipity_event_sidebarhider.php:226).
the problem is, that the link gets added by the included .js which has the default style hardcoded and not set via a css selector.
i tried to fix my formatting problem (hider elements not in the same line) by changing this hardcoded style (adding display:inline and removing other stuff) which was not successful.
i then tried a more brute force method by putting the link element inside the title <div> which worked fine. code of sidebarhider.js:78 below

Code: Select all

            title.innerHTML = "<div >" + title.innerHTML + "<a href=\"javascript:sideBarHide("+i+","+j+")\" id='sbl_"+i+"_"+j+"' style='text-decoration:none;margin-right:3px'>"+linkText+"</a></div>";

dunno how you should change this, but at least the configurable style should be used(?).

[garvinhicking]

Hi!

I don'T really like adding the quantity to the sidebar output, I think in the popup bubble it doesn't waste so much screenspace.

You can also use the ".container_serendipity_plugin_freetag a { white-space: nowrap}" method in your style.css, because this way it only affects the sidebar plugin for freetags, and not the sidebarhider for example.

HTH,
Garvin

[bugrep]

I don'T really like adding the quantity to the sidebar output, I think in the popup bubble it doesn't waste so much screenspace.

the categories sidebar plugin has an option to en/disable the count. that put the idea in my head in the first place.
and i wanted to get rid of the categories all together. i thought they are too static, until i recognized that i can select multiple categories for an entry.
the only thing, that i still like better is how new tags are created; by just using them on the create page.
this behaviour combined with all the features of categories (tree-like, output of the usage count in the sidebar, sort order (altough one could want other attribues "most recently used" etc.), would make them perfect for me.
are there any plans to change the category creation? do you even agree with my view about the creation or do you think its good as it is? maybe i could hack in a tag-like creation for them?

You can also use the ".container_serendipity_plugin_freetag a { white-space: nowrap}" method in your style.css, because this way it only affects the sidebar plugin for freetags, and not the sidebarhider for example.

will look into it, but i think you missed the most imporant point about the sidebar plugin (== i should write shorter, more significant postings :)
the style, one can set in the options of that plugin are never actually used, because the style is hardcoded in the .js:

the sidebar plugin provides an option to set the style of those hider elements, which gets saved in the database correctly and produces a css declaration named "serendipitySideBarLink" (serendipity_event_sidebarhider.php:226).
the problem is, that the link gets added by the included .js which has the default style hardcoded and not set via a css selector.

[garvinhicking]

Hi!

are there any plans to change the category creation?

Currently not; IMHO creating a new category is currently just a matter of 3 mouseclicks and can be done in a seperate tab. But if some developer wanted to implement a on-the-fly categorization, I'd happily add it. But creation of categories as an input field like tags is IMHO problematic. You couldn't easily support parent-id's of categories, so there'd need to be some kind of popup to create the category on the fly.

will look into it, but i think you missed the most imporant point about the sidebar plugin (== i should write shorter, more significant postings

Yeah, I missed that. The problem is you heave too many (different) things into one posting. That makes it hard for me, I'm the more of a "step-after-step" guy.

the sidebar plugin provides an option to set the style of those hider elements, which gets saved in the database correctly and produces a css declaration named "serendipitySideBarLink" (serendipity_event_sidebarhider.php:226).
the problem is, that the link gets added by the included .js which has the default style hardcoded and not set via a css selector.

Hm, I didn't code that part of the plugin and never got through the concept of it. I cannot offer a solution to that currently, I believe much of the concept needs changing so that the JS takes the CSS as a variable declared somewhere.

Regards,
Garvin

[bugrep]

are there any plans to change the category creation?

Currently not; IMHO creating a new category is currently just a matter of 3 mouseclicks and can be done in a seperate tab. But if some developer wanted to implement a on-the-fly categorization, I'd happily add it. But creation of categories as an input field like tags is IMHO problematic. You couldn't easily support parent-id's of categories, so there'd need to be some kind of popup to create the category on the fly.

i thought of a filesystem-like mapping + ',' for seperating like its done with tags (e.g. "topcat/childcat/grandchildcat, anothercat, anothertopcat/anotherchildcat"). shouldnt be too hard to parse+map(?)

Hm, I didn't code that part of the plugin and never got through the concept of it. I cannot offer a solution to that currently, I believe much of the concept needs changing so that the JS takes the CSS as a variable declared somewhere.

hmm... my knowledge about webdesign is more than limited... but cant the js output a link with an ID, that matches a CSS (or more like the other way around)?
i think it was meant to be like that when implemented. the php outputs the css dynamicaly and the javascript just outputs the links with constant IDs/selectors.
and the browser combines them just like it does for static (as in php-produced) html content?
then there would be no need to "changing so that the JS takes the CSS as a variable declared somewhere."
the only thing that would need to be changed is the .js to contain the selector IDs.
did i miss something completely?

[bugrep]

in the meantime i patched the category_dhtml_menu to include an option for showing the entry count just like the normal category sidebar plugin.
actually almost everything is stolen from plugin_internal.inc.php :)
id add those XML rss buttons too, but those are so huge, this would look awful in the tree menu imho.

the file is just a plain text file... stupid forum :/

dhtml_entry_count_patch.txt.zip

(5.1 KiB) Downloaded 239 times

[bugrep]

apropos the XML icon: the why section of http://www.feedicons.com/downloads/readme.pdf is interesting imho.
you may wanna include this/those and set it as default instead of templates/default/img/xml.gif
and its smaller too

[bugrep]

and another one
this adds feed icons+links to the category tree too.
it includes the previous patch.
it looks quite good even with the default (big) xml.gif!

dhtml_entrycount_and_feed_patch.txt.zip

(6.28 KiB) Downloaded 294 times

[garvinhicking]

Hi!

Thanks, I've patched your category dhtml menu.

About the CSS/JS of the sidebarhider, I currently do not have the spare time to investigate the issue. You might also be able to simply add the style through your style.css instead of hardcoding the style values inside the plugin configuration for the time being.

About the XML icon, the bulletproof template for example supplies different XML images, it's up to the template to specify those. I'd like to keep the current ones of older templates like they are.

Regards,
Garvin