Extension talk:Wikilog

PHP Warnings
This looks cool, but it won't load. I'm getting this error from update.php on 1.14 current: PHP Warning: call_user_func(WlFeed::Setup): Unable to call WlFeed::Setup in /x/eng/wiki/xwikid/includes/Setup.php on line 294 PHP Warning: call_user_func(Wikilog::ExtensionInit): Unable to call Wikilog::ExtensionInit in /x/eng/wiki/xwikid/includes/Setup.php on line 294


 * Hi, it seems to be a small incompatibility between different versions of PHP, on how they call class static functions. I have fixed this in versions 0.6.2 and the latest trunk. Please upgrade and tell me if it fixes your problems. Thanks! --Juliano 18:48, 6 October 2008 (UTC)

WikiLog Review
Bliki extension for MW is something must-have. WikiLog is by far the best until now. This is professional : new namespaces, flexibility ( more users on a blog, several blogs), rss feeds, special pages for management. Waiting for new wikilog features... Until then: Congratulations! --EuroDomenii 22:38, 10 December 2008 (UTC)


 * Thanks! :-) --Juliano 17:57, 1 June 2009 (UTC)

Not quite working.
I can create and access the blog tab and page but:


 * 1) When I try to access the Wikilog Tab I'm getting:
 * 2) * Fatal error: Call to undefined method Xml::fieldset in /home/.../extensions/Wikilog/WikilogMainPage.php on line 212


 * 1) When I try to access special:wikilog I get error:
 * 2) * Fatal error: Class 'FormOptions' not found in /home/.../extensions/Wikilog/SpecialWikilog.php on line 47

Not sure if I missed something in the instructions?

Thanks kent@kentgrey.com


 * Thanks for your interest in Wikilog.
 * What version of MediaWiki you are using? From the messages, it seems that you are using some pre-1.13 version, which Wikilog is not compatible with.
 * Your only option is to upgrade your MediaWiki installation.
 * --Juliano 17:57, 1 June 2009 (UTC)

Doing the update seems to have done the trick.

Thanks

Tags
First, great extension. It's works seamlessly with our install of Mediawiki (1.15).

Can you give a brief explanation of the tags feature? I didn't see any instructions on how to use it or how it differs from just using Categories for each blog post.

thanks --38.99.130.13 17:26, 17 June 2009 (UTC)


 * Hi! (I moved your talk to the bottom of the page, in order to keep the chronological order of the talk page).
 * Thanks for your support! :-)
 * Tags are really just another category system, but specific to wikilog articles. You should really consider using the builtin MediaWiki categories if it suits your needs. That is why tags are disabled by default. I created the tags system just because I wanted an additional category system that is more fine-grained than categories.
 * For example, one may have a blog about open-source topics in general, and have an article about Linux security, filled in the categories "Linux" and "Security". These categories are well-structured and part of the blog. But the same article may talk about a multitude of minor subtopics, like "Gnome", "iptables", "TCP/IP", etc... These minor subtopics are not the direct focus of the blog, so it doesn't convince the creation of a dedicated category, but it may be useful for searching for these minor subtopics. This is where I intended to use the tags.
 * In other words:
 * Categories provide a formal categorization about the subject of articles, as it is for the rest of the wiki. Categories deserve a dedicated page in the  namespace, and wikilog articles usually fit in a few categories only.
 * Tags provide a messy and ad hoc list of minor subjects that wikilog articles may happen to talk about. These subjects don't justify creating dedicated pages for all of them. The list is supposed to be virtually infinite, and the authors of wikilog articles are not supposed to care about creating dedicated pages for each tag, as it is with categories. Wikilog articles may fit in a lot of tags, without much concern (the default configuration limits to 25 tags per article).
 * Currently, tags are not displayed anywhere, but they are stored and can be searched using  if you have them enabled in the config. In intend to allow displaying tags in both the main blog pages and article pages, and also provide a way to display tag clouds (tags that are more frequent displayed in bigger fonts, etc).
 * To add tags to wikilog posts, put this somewhere in the article (suggestion: near the signature, categories, etc):


 * To search for posts with a given tag:.
 * If you can, please tell us the link to your wikilog! It helps me to see how people are using the extension, to collect use-cases and drive future changes that will benefit current users. :-)
 * Best regards, --Juliano 19:44, 17 June 2009 (UTC)

Brilliant
Installed flawlessly in MW 1.14 :)

Question: I just wonder if you plan an upgrade path for future releases ? I don't mind if functionalities and buttons etc. will disappear/move, but it would be cool to be able to keep the contents (blog entries).

Other comments:
 * To publish a blog post, don't forget to sign at the end ( --~ ).
 * To include blog contents into a page, e.g. the main page, use an extension like Extension:RSS, though it would be nice to have a "Wikilog" tag just for this purpose sometimes in the future :). Demo: http://edutechwiki.unige.ch/en/


 * Hi Daniel,
 * Thanks for your support! :-)
 * Regarding your question: Yes. I have a few things planned until the version 1.0 release. All main features are already present, I just have to fix some minor things (regarding the deletion of articles, cascading the deletion of the talk pages and article comments) and documentation. The main thing that is holding the final 1.0 release is the documentation... if people don't know how to use the extension, it loses a lot of its usefulness.
 * After version 1.0, I have a few things in my mind: tag clouds, a calendar (each day links to a page with that days posts), category list (probably based on Extension:CategoryTree, but with the number of articles in that category along the name), etc.
 * You don't have to worry, all future upgrades will preserve your data. :-)
 * Regarding including blog contents into another page, there is a better way of doing that... That is why I really have the documentation my top priority. Anyway, try this:
 * 1. Create a template, for example, with the following contents:

 |


 * 2. Add this code to the page you want to include the blog contents (change   to the name of your wikilog):


 * This includes the list of articles of your wikilog, using the template specified, at most 5 articles. There are more fields you can use in the template. You may check WikilogPager.php, around line 250 for a list of them.
 * It is a better solution than using Extension:RSS, since the information already comes directly from the wiki itself. With the RSS extension, the information has to do a round trip through the RSS feed and then be reformated into the page.
 * Feel free to ask if you have any other question! :-)
 * Best regards, --Juliano 19:44, 17 June 2009 (UTC)


 * Is there a chance you could make a property available whether there is "more" in the article than in the summary? (To dynamically show the "more..." link in the template). I could do it with a hack, but I'd love to see it in the original code, as updating would stay easier for me. --83.65.127.178 12:30, 30 October 2009 (UTC)


 * Yes, there is! I didn't put it in 1.0.0 since I had this release pending for a few weeks. But I added it to the current snapshot, revision 26398d9b1e. It will be available from MediaWiki svn in the next sync, and then on version 1.0.1 (probably in a week or so).
 * The new parameter is, it can be tested with ParserFunctions. Documentation.
 * --Juliano 20:57, 30 October 2009 (UTC)


 * Great, thanks for that. But did you test the feature yet? I manually implemented your code changes, and in my blog the hasMore is always true, even for two-liners without any headings...--83.65.127.178 08:13, 3 November 2009 (UTC)
 * f.e. this Neues Projekt gestartet. Details gibts hier: Libraries für PLC Programme

has the set. Or does your routine recognize the signature as "more"? This would be very bad...


 * Yes, it is supposed to behave like this. Using   tags anywhere in the article will always trigger the hasMore parameter.  For the extension, you are providing an excerpt for the article in between these tags, everything else should appear in the full article view, that it has to be linked.  In this case, you can just drop the summary tags, so wikilog knows that there isn't any specific part of the article defined as summary.
 * --Juliano 13:24, 3 November 2009 (UTC)


 * Hm. forgot to save today's post. I forgot to mention that I tried it before without any tags. Same effect. Or did I mess up my if clause? This line here without the nowiki tags: always returns the |→ mehr... part. No matter how short the article is or if any tags are used. Same on the article I mentioned above, after removing the summary tags... --194.24.138.3 14:46, 4 November 2009 (UTC)


 * I tested it in my wiki, and it is working (see the "nothing else" text for the post without summary, check the template source here). I guess something is not right with the changes you patched manually. Please, try an updated clean copy from MediaWiki svn. --Juliano 15:51, 4 November 2009 (UTC)


 * You were right, messed up something with the patch. Grrrrrr. Thx :) But one more thing: The empty line between your summary and the "nothing else" text, where does it come from? I experience the same behaviour if I'm not using summary tags. I always get an empty line added. If I use summary tags, it doesn't happen. This kinda messes up the design. Again, it only shows up with the automatic summary.


 * This is a peculiarity of the MediaWiki parser. I'm currently investigating how it can be modified so that this doesn't happen. Basically, it is considering too many blank lines in both the post and the template. If you put the in the same line as the text in the article, and remove the newline after  in the template, these extra lines disappear. E.g.:

Article: Text...

Template: {{#if: | ...


 * I'm trying to change this behavior so that the user doesn't need to pile everything in one line in order to make it look right.
 * --Juliano 13:46, 5 November 2009 (UTC)

Inclusion template works - example templates
Cool, thanx ! (Sorry I was absorbed by other stuff and didn't see your message before). The template I chose to create for the wiki front page goes like this for now: This template allows to include blog entries from a wikilog (bliki).

Substitute "Blog:_blogname_" by the name of your blog, e.g. Blog:DKS

|

&mdash; by -

Now to help a tiny bit with documentation. Below is template that you can install for testing and that also includes 2-3 hints if you look at it

- Daniel K. Schneider 12:59, 26 June 2009 (UTC)


 * Hello Daniel,
 * Thanks! I'll include this documentation soon. I'll start a Help:Extension:Wikilog soon with this information. --Juliano 19:51, 26 June 2009 (UTC)

Wikilog transclusion rendering bug
There seems to be a little rendering bug.

Workaround: Include the template before any title or use HTML h1 tags. Demo page: http://edutechwiki.unige.ch/mediawiki/index.php?title=SandBoxes&oldid=21229

Version 0.7 - Mediawiki 1.14.0

If I have code like this:

New testing
I get this: Contents [hide]

* 1 UNIQ6205a1d6126da8ab-h-0--QINU Bliki testing * 2 New testing * 3 Testing Sandbox * 4 Variables * 5 Collection extension

1 UNIQ6205a1d6126da8ab-h-0--QINU Bliki testing [..... ok]

2 New testing

Btw this is not an issue for me. I use this feature only on the home page and it doesn't have wiki titles :)

-- Daniel K. Schneider 12:38, 26 June 2009 (UTC)


 * Got it! I fixed the bug in latest trunk (development) revision. Thanks for finding it and reporting! :-) I'll soon release a fixed stable version (probably 0.7.1) containing this fix. Thanks again! :-) --Juliano 19:51, 26 June 2009 (UTC)


 * Fixed in version 0.7.1. Thanks for reporting! --Juliano 03:16, 2 July 2009 (UTC)

Same error in Wikilog 0.7.2
I am also experiencing this problem above and when I attempt to transclude my blog within Header Tabs. The Recent Developments tab (contains Wikilog) also displays the same text when not active.



I currently have Wikilog version 0.7.2 installed.

-Dgennaro 19:46, 1 September 2009 (UTC)


 * Hi Dgennaro,
 * Thanks for reporting!
 * I fixed the bug in the current trunk. You can download it using Subversion from the URL in the extension page ("Development" link). The current fix is temporary, I'll try to refactor some code before releasing the next version that will fix it definitely.
 * Regards,
 * --Juliano 14:38, 2 September 2009 (UTC)


 * Hi,
 * Version 0.7.3 is released, this bug should be fixed now. Most parser tricks that would result in this behavior were removed in favor of recursive tag parsing.
 * --Juliano 00:39, 4 September 2009 (UTC)

Renaming of wikilog post titles (feature request)
Currently (v 0.7) it is possible to rename a post but the title of the post remains the same. E.g. /Blog:DKS/Table_PCs will rename to /Blog:DKS/Tablet_PCs but the title stays, e.g. Table PCs

So this is feature request for a next version :)

For other readers: In the mean-time the workaround is to edit the db, i.e. the wikilog_posts table, column wlp_title. But if this procedure formats your harddisk, don't blame me !

- Daniel K. Schneider 09:26, 1 July 2009 (UTC)


 * Hi Daniel,
 * This is not a feature request, it is a bug that should be fixed. :-) The code to handle this is pending. It is a little tricky because it needs to update not only the wikilog_posts table, but also move the talk page, and all talk page comments. It is not difficult, just a little tricky, and need a few unit tests. I was delaying the implementation. I'll handle this during the following week (if not everything, at least the wikilog_posts update part that is very easy) and then release a new version.
 * Thanks for reporting. :-)
 * --Juliano 03:26, 2 July 2009 (UTC)


 * Fixed in current trunk.
 * --Juliano 04:12, 3 July 2009 (UTC)


 * Juliano,
 * I'm using the extension v0.7.1 seems to still be suffering from this bug. I got around it by not having a header above my call to Special:wikilog, but would appreciate if your next release could try to address this again.
 * CWinDC 15:25, 21 August 2009 (UTC)


 * CWinDC,
 * The fix was sitting on the trunk branch and I forgot to release a new version with it. I've just released version 0.7.2, which should fix this bug. Please, check it. You will need to re-rename the article in question in order for Wikilog to update the database with the new name.
 * Please, inform me if it works. Thanks!
 * --Juliano 16:08, 21 August 2009 (UTC)

Database error
After installing Wikilog I a receiving the following error:

'''A database query syntax error has occured. This may indicate a bug in the software. The last attempted database query was:'''

(SQL query hidden)

'''from within function "IndexPager::reallyDoQuery (WikilogSummaryPager)". MySQL returned error "1146: Table 'wikidb.mw_wikilog_posts' does not exist (localhost)".'''

Another problem I am having is that when the Wikilog extension is installed the font size throughout the entire wiki increases significantly. This distorts the layout.

I am running MediaWiki 1.14.0.

-Dgennaro 19:30, 1 July 2009 (UTC)


 * Hello Dgennaro,
 * It seems that the database wasn't updated. Did you run maintenance/update.php after installing Wikilog? If so, did it report that it was creating the proper tables, or did it report some error?
 * The font size change can be caused by PHP issuing warnings before the beginning of the HTML output, perhaps related the missing tables. This confuses the browser and alters how it renders the page. Use the "view source" (or equivalent) feature of your browser to see if there is any junk being issued before the HTML markup.
 * Regards,
 * --Juliano 03:32, 2 July 2009 (UTC)


 * Thanks for the help Juliano.
 * One problem was the database error and the other, larger text/hidden characters was resolved by upgrading to v0.7.1 that was released today.
 * Keep up the good work!


 * -Dgennaro 18:31, 2 July 2009 (UTC)

Call-time pass-by-reference Warnings
Not a big issue but the latest code in the trunk that fixes Dgennaro issue from Sept 1st has 2 Call-time pass-by-reference warnings:

WikilogUtils.php - Line 93 WikilogItemPage.php - Line 159

We are using PHP 5.2.9.2 and MediaWiki 1.14.0

I have currently change my php.ini to:

allow_call_time_pass_reference = on

and restrated the environment.

Wolcott 16:45, 3 September 2009 (UTC)


 * Hi Wolcott,
 * Thanks for reporting!
 * I just fixed this. Could you check it again?
 * Best regards, --Juliano 19:45, 3 September 2009 (UTC)


 * Hi,
 * Version 0.7.3 is released, it should fix this bug.
 * --Juliano 00:42, 4 September 2009 (UTC)

Fix in 0.7.3 missing in 0.8.0 (Transclusion Bug)
The fix that you made to 0.7.3 is not in 0.8.0. See discussion above:


 * http://www.mediawiki.org/w/index.php?title=Extension_talk:Wikilog#Same_error_in_Wikilog_0.7.2


 * Hello Wolcott,
 * Thanks for reporting!
 * The fix was still there, it was another related change I did without redoing the proper tests that broke the parser again. The regression was caused by revision r454. I fixed it again in r471 and just released version 0.8.1. Please check and report.
 * Regards,
 * --Juliano 21:00, 15 September 2009 (UTC)

I will be back in the office on Thursday and will check it out. --Wolcott 12:05, 16 September 2009 (UTC)

Version 0.8.1 looks good so far ... --Wolcott 12:17, 17 September 2009 (UTC)

Session Problems
First at all great extension it works really good, but we have one problem

A user wants to create a new blogentry (mywiki.com/index.php/?title=Blog:Example&action=wikilog) Hes hitting the url and then we got an login error, the user is logged out and must relogin to the system. After that he reopens the url and can make an entry. How can we solve this issue? MediaWiki 1.15.1 PHP 5.2.10 (apache2handler) Wikilog (Version 0.8.1)

62.225.129.212 13:24, 28 October 2009 (UTC)!


 * Thanks.
 * This problem doesn't seem to be related to Wikilog. I can't reproduce it in any of my wikis. It may be caused due to the MediaWiki configuration or other installed extensions. The Wikilog extension doesn't touch anything related to the MediaWiki login procedure or session cookies.
 * --Juliano 16:27, 28 October 2009 (UTC)


 * We´ve just installed Wikilog-extension :/
 * MediaWiki stores my login in a file in my session folder sess_iubh3ilbci9s8hf1d3j0sfg0q4
 * If i try to add a wikilog entry it creates another file sess_7o1hm2ffmcmoq7dgf1j8f1ovo3 and my login session is deleted.
 * Thanks and best regards
 * --62.225.129.212 12:35, 29 October 2009 (UTC)


 * Hello,
 * Sorry, but there is very little I can do with this much information. Wikilog doesn't touch anything related to the user session. Just accessing the 'wikilog' tab doesn't do anything special other than intercept the page view method to show the page, akin to the 'history' or 'edit' tabs.
 * I'm afraid you may need to debug this yourself in order to collect more information that connects Wikilog with the problem observed. You may want to temporarily enable $wgDebugLogFile in order to have a comprehensive log of MediaWiki execution while going to that tab. The log will tell you when sessions are started and ended.
 * If you provide the URL to your wiki, I may do some remote tests for you.
 * Regards,
 * --Juliano 13:29, 29 October 2009 (UTC)


 * Thanks for the hint with $wgDebugLogFile
 * Short Overview (debug_log.txt):
 * First request goes to /index.php?title=Blog:Example&action=wikilog
 * Second request to /opensearch_desc.php <-- right?
 * Next /index.php?title=Special:UserLogin&returnto=Blog:Example
 * Well, i think it´s not more a problem with Wikilog - i will check my server configuration...there is a small chance to fix this because i have another problem with my timezone...maybe wikilog or mediawiki get a cookie error and kicks me out.
 * Thanks for your help, but it´s not possible to access my Wiki, because its just local availble
 * --62.225.129.212 14:43, 30 October 2009 (UTC)


 * You are welcome.
 * The second request is not related to Wikilog, it is done automatically by your browser to provide parameters for the integrated search box (probably near the address bar). For the first request, you should look for "setcookie:" and "Logged in from session" lines. They would tell you (along with nearby lines) when and why you were logged in/out.
 * --Juliano 16:53, 30 October 2009 (UTC)


 * Hey Juliano
 * I solved the problem. I laughed alot about this :). There was an error in my URL
 * For Example:
 * Opening an Blog-article URL=http://mywiki.domain.local/index.php/Blog:Example
 * Creating a new Blog-entry URL=http://mywiki/index.php?title=Blog:Example&action=wikilog
 * I changed it to URL=http://mywiki.domain.local/index.php?title=Blog:Example&action=wikilog
 * Now it works perfect :)
 * --62.225.129.212 11:59, 13 November 2009 (UTC)


 * Oh, sure...
 * Different domain names means different cookies. Makes sense. Always make sure that you access the site using the same domain name, and also check that the site doesn't redirect you to the alias.
 * --Juliano 19:33, 13 November 2009 (UTC)

Too stupid to use it?
Hi Juliano. I tried to install your extension on my 1.15.1 MW Wiki. Install was no problem at all, special page gets added, but... (there's always a 'but') When I create a page in the Wikilog namespace (I also tried the "Blog" ns), absolutely nothing happens. It behaves just like any other article, I don't get any special Wikilog tabs or anything. Also a subpage behaves like a normal subpage. Could you give me a hint what I missed out?

--83.65.127.178 10:02, 29 October 2009 (UTC)


 * Hello,
 * This is strange. Did you setup the namespace like stated in the installation instructions?
 * Could you provide an URL to your wiki, so that I can take a look?
 * Regards,
 * --Juliano 13:32, 29 October 2009 (UTC)


 * Yep, in fact I copy/pasted the two lines to my LocalSettings.php
 * My Wiki is corporate network only, so that's not possible :(. Another information that could help is, that in the WikiLog help, where you try to display the ns names inline with the text (Help:Overview_of_wikilogs), it displays nothing instead of the names... Could it be connected to the fact that I use ns 100 and 101 for something else and start with 102?
 * --83.65.127.178 15:23, 29 October 2009 (UTC)


 * Yes, in this case, you must adjust the Wikilog::setupNamespace(...) line to an unused namespace number in your wiki. Usually, that call should fail if it is provided a namespace number that is already used for a different purpose, but if the namespace is set after that line, it will override Wikilog.
 * Check your configuration. If you write  in a page, it must show the namespace listed in LocalSettings.php.
 * I'm going to release v1.0 today. I would like to know if your problem is just a configuration problem.
 * --Juliano 15:58, 29 October 2009 (UTC)


 * You do not understand... I DID adjust the namespace number in setupNamespace to the first unused equal number (102). Nevertheless it did not work. Now that I readjusted it to 100, it started working. --83.65.127.178 07:33, 30 October 2009 (UTC)


 * I can't reproduce it here. My development wiki has two Wikilog namespaces 102 and 104, and it works.
 * I think it is a namespace clash or some extension conflict, but without access to your configuration is impossible to say.
 * In order to help, I need detailed steps of how to reproduce the bug like in your environment. Starting with a blank copy of MediaWiki, the installation of the extensions previously present, the configuration of the previous namespaces and finally the Wikilog setup and what you did to determine that the namespace prefix wasn't present. Also, the resulting LocalSettings.php after all these changes.
 * This is necessary in order for me to reproduce the bug here.
 * --Juliano 13:34, 30 October 2009 (UTC)

Wikilog broken with 1.16alpha-wmf
Hi, I'm running bleeding-edge nightlys of the main code and the extensions. I have been running Wikilog 1.0.0. There's two problems:


 * wikilogImportDocumentation.php is broken because it expects rebuildrecentchanges.inc and that's been folded into rebuildrecentchanges.php


 * Special:Wikilog is gone. I've attempted known working versions of Wikilog back to 0.8.1 and that gives an error message from WikilogPager.php, later versions simply inform me there is no such page despite it being listed in specialpages.

Apart from that, the extension seems to be working in all other respects.

--Ewe2 02:04, 2 November 2009 (UTC)


 * Hi Ewe2,
 * Thanks for reporting.
 * I fixed the problem with wikilogImportDocumentation.php in r58418, please update and test.
 * About the problem with Special:Wikilog, I can't reproduce it here. The page is working. I don't know what may be causing your problem, but please, check that you are really using the latest trunk for phase3 (MediaWiki main directory). For MediaWiki 1.16, Wikilog depends on a very recent change added in r58350 in order to work. If you haven't updated phase3 in the last 3 days, this may be the problem.
 * Keep me informed.
 * Regards, --Juliano 04:19, 2 November 2009 (UTC)


 * Thanks Juliano, the new nightly r58426 seems to have fixed my bizarre issue which was with r58400. The documentation works fine now.
 * --Ewe2 15:04, 2 November 2009 (UTC)

Great Extension, but a couple of suggestions...
...or are my suggestions below already there and I'm missing something? I am using Wikilog for a dual purpose on my wiki. I'm using it for users to be able to submit reviews on just about everything on site. As well I am using it for users to submit memorable quotes on a limited number of pages on site. I have two respective namespaces set up for these tasks, "Review" and "Quotes". What I was hoping to do is to be able to use either the tags or categories feature of Wikilog to embed quotes on other pages, but I only seem to be able to embed quotes by specifying the page name that the quotes belong to. My wiki is a fan wiki for a show, and I have it set so people can add quotes from episodes, but I want to be able to tag each quote with the characters that said them and then call on those tags to embed all quotes from a particular character on the page for the character, either through the use of tags or categories, but I can't seem to get either to work with the current version of Wikilog. Am I missing something, or is it possible to incorporate this feature into the next version of the extension? Thank you.--74.198.12.14 16:07, 24 March 2010 (UTC)


 * Yes, it should be possible, depending no how you organized your wikilogs. It depends not only on the namespaces, but also how you set up wikilogs and articles.
 * For example, consider that namespace "Quotes" has a wikilog named "Quotes:Character quotes", and that the many quotes are stored as articles in that wikilog. Each article has a category like "Category:Quotes by XXX". Then, to embed the 5 most recent articles with quotes from character XXX, you add this code to a page:


 * You can do the same with tags, but tags were created for a more informal way of grouping articles. It seems to me that categories is best for your use-case. You can also customize the listing using a template. Check Help:Embeding wikilogs for more information.
 * --Juliano 16:29, 24 March 2010 (UTC)


 * Sorry I wasn't logged in before. Thank you for responding though.  I think I had my category names improperly formed.  I was using slashes in them, anyhow it wasn't calling them up.  I also had noticed some examples had semi-colons between the parts of the embed code and others had slashes; I had been using the semi-colons..  But I've replaced the slashes in the category names I was using with colons and replaced the semi-colons with slashes and it seems to be working without any problems now.  Thanks again. --Ds093 19:49, 24 March 2010 (UTC)

No Wikilog-Tab is added in 1.16 with Vector-Skin
Hi there, I use MW 1.16 with Vector-Skin. With Monobook-Skin there are no Problems, but if i use Vector-Skin the Wikilog-Tab disappears.

Is this Problem known and is there a solution or workaround available? Thanks! --Heinoth 00:39, 9 April 2010 (UTC)


 * The new vector skin uses different hooks to set the links on the top of the page. I'll fix this and release a new version soon.
 * Thanks! --Juliano 14:05, 15 April 2010 (UTC)


 * Fixed in r65679.
 * --Juliano 03:06, 30 April 2010 (UTC)

Liquid Threads
For some reason comments are not recognized when using the Liquid Threads extension. --Smile Lee 07:09, 13 April 2010 (UTC)


 * Hi,
 * This extension does not claim any compatibility with LiquidThreads. Wikilog comments are completely independent of LiquidThreads discussions. Both extensions aim for different goals.
 * LiquidThreads provides complex discussion forums, one per talk page, with a bunch of features like discussion titles, archival, summaries, moving discussion between pages, etc... Wikilog, on the other hand, provides a much simpler interface for the occasional visitor of your blog: there is no need to write a "Subject" line for your comment, it allows anonymous posting (the visitor chooses their pseudonym without having to login), provides a moderation queue (to avoid spambots) and possibly other features in the future that are more suited for a simple commenting interface than a full-fledged forum software.
 * When I started this extension, I considered using LiquidThreads or another third-party extension to provide the commenting interface, but LiquidThreads was very immature at that time and it was not worth spending my time trying to fix it. All other options lacked in some way: stability, captcha support, proper individual comment storage (for counting, syndication), etc.
 * It is possible that, in the future, the interface between Wikilog and WikilogComments will be abstracted, so that the user can replace it with anything else that provides the same functionality (in fact, I want to make WikilogComments a separate extension).
 * Regards, --Juliano 14:26, 15 April 2010 (UTC)

Moderated Anonymous Comments still visible
Even with $wgWikilogModerateAnonymous = true;, there are 2 visibility problems:
 * 1) The comment appears in RecentChanges
 * 2) Suppose we have Blog_talk:MyBlog/MyPost. An Anonymous comment is not visible on this page( "waiting for moderation"), but is full visibile on the page Blog_talk:MyBlog/MyPost/c0000XX. The user could access it also via RC.

Thanks in advance, --EuroDomenii 22:29, 11 May 2010 (UTC)


 * Hello EuroDomenii,
 * It is still possible to read pending comments by numerous ways, because that is the nature of a wiki. The comment moderation feature was designed so that you can control what shows in the talk page itself, so that spam is not indexed by search engines, other casual visitors don't have to read unmoderated foul language posted by previous visitors, etc. The current implementation achieves that.
 * In order to provide more than that, we would have to make changes that are not adequate for a wiki. Wikilog definitely won't try to restrict all read access to unmoderated comments, this is not planned and I don't want to step there. Wikilog will only make so that comments won't be displayed directly in the talk page until they are accepted.
 * RecentChanges has to display all changes to the wiki, including new pages added by the Wikilog comment interface. If we were to change that, it could be seen as if Wikilog is tampering with the correct behavior of MediaWiki, perhaps even a vulnerability. In the case of directly accessing the comment page, perhaps we could force a robots="noindex,nofollow" meta tag on those pages, along with a banner warning that the user is visiting the page of a comment that is pending approval and that the moderators may not endorse it.
 * The rationale for these decisions is better explained in Security issues with authorization extensions. Please, take a look at it.
 * If you have suggestions to improve how Wikilog does comment moderation, I would like to hear them. Just remember that we have to respect MediaWiki limitations as a wiki. Ok?
 * Regards, --Juliano 02:29, 12 May 2010 (UTC)

Requests
Juliano -

This extension is awesome! If you have any plans for future development, I would like to request some features.

--PerkinsTaylor 04:33, 23 June 2010 (UTC)


 * Thanks!
 * Your contribution is really welcome! However, there a few general points I would like to make:
 * This kind of discussion is better suited for the mailing list, since it is easier to send patches and discuss the changes.
 * It is highly unrecommended practice to keep lists of "hacks" that users copy/paste into their copy of the code. Not only I do not recommended it for Wikilog, but it is not recommended for MediaWiki either (extensions exist for this very reason), and it is not recommended for open-source projects in general. Some of the reasons for this are that (1) users are not developers, (2) installing hacks would mean that users would become attached to a possible obsolescent version of the software, (3) upgrading the software becomes a burden when you have to reapply all those "hacks", (4) generally, the existence of "hacks" means that there is a problem or deficiency with the software that should be fixed instead. Even if a particular feature is not going to be implemented directly, a better alternative is to create hooks that allow that specific "hack" to be implemented through an extension, still without expecting the end-user to change any code directly within Wikilog.
 * If you are going to suggest changes to the extension, do not use the last stable version (v1.0.1 as of this writing). The stable version, which is the one directly available for download, is not expected to receive any more changes except backporting for stability, security or important bug fixes. All new features are added to the current development version, which can be downloaded via the Svn or Hg repositories. The current development version is the one which will become 1.1.0 in the future (hopefully, I'm planning to release it along with MediaWiki 1.16). Some of your suggestions are based on code that doesn't exist anymore, and so they can't be applied. For example, there is no 'wikilog-item-brief-header' system message anymore!
 * I'm answering the other specific points inline, keep reading below:
 * --Juliano 22:28, 23 June 2010 (UTC)


 * Wow. That was quick.


 * I understand all your points above. However, my experience is that there are a number of extensions posted at Mediawiki which seem to have been abandoned or are no longer maintained by their original developers.  I have often been forced to manipulate an extension just to get it to work correctly, and I am appreciative of others who publish examples of what they have done to solve the issues that I face.  For the same reason, when I come across a good idea that needs a little tweaking, I feel a responsibility to share what I've found with the community in case the developer is incommunicado and others find the need to make changes themselves.  It is apparent from your response that this is not the case with Wikilog.  I appreciate your continued work on this excellent extension and I apologize if my approach caused a disturbance.


 * You note above that the existence of "hacks" means that there is a problem or deficiency with the software. I guess I agree that this is the case with some software, but I cannot agree that there are problems or deficiencies with Wikilog. All of the "hacks" I've suggested are cosmetic changes to suit personal preferences. I appreciate that you have considered all of my requests, but I don't expect you to revise the extension to suit every last one of my wishes. Where there is something I'm am looking for that may not be appropriate to include in Wikilog, I'll take it upon myself to develop my own solution. But after I do, I think that there should be some place where I can share what I've done with others who may be looking for a similar unique feature without sounding critical of what has been included in the extension. I think that the term "hack" has a negative connotation, and I had considered calling the page "Advanced Configuration," "Customization," or something like that. But I also think that it is important that the name clearly identifies the rogue nature of the submissions included therein and I wasn't able to come up with a more fitting name.


 * My intent for associating each suggestion with the current version was so that a simple statement like "this issue is addressed in version ... " could be used to negate each of the sections as they were addressed.


 * Thanks for your responses below. Please see my comments.


 * --PerkinsTaylor 18:53, 24 June 2010 (UTC)


 * Yes, Wikilog is still in active development. If I decide, for any reason, to discontinue or drop from development, I'll make sure to post a notice in the extension page.
 * Still, for the reasons I mentioned, it is not correct for end-users to make modifications to software code by themselves, unless they intend to fork the extension (at which point they cease being end-users and become developers). All the hacks posted are either bugs that were fixed or misunderstandings of how the extension works.
 * --Juliano 01:38, 25 June 2010 (UTC)

Marginalia in a Blog Page
By editing the Wikilog page, a user can add content above the blogroll. However, there doesn't seem to be an easy way to add content on either side or following the blogroll. I find it useful to use a right margin to include archives, teasers, blogger bios, images, navigation tools and other elements. These items are typically specific to individual Wikilogs, they are subject to frequent changes, and I prefer to give editors the ability to edit them, so it is important for the content to be editable from within the wiki.

A hack to create marginalia can be found at Extension:Wikilog/Hacks.

--PerkinsTaylor 04:33, 23 June 2010 (UTC)


 * It is possible to add content to both sides of the roll without making any changes to the extension, using only CSS! I use this in my own blog at Memory Leak. Just add the following to your MediaWiki:Common.css page:
 * This will allow any box to float and flow along the margins of the roll. Just create a  in the wikilog page, for example, and it will become a floating box to the right.
 * Wikilog doesn't offer an easy way to add content after the roll, and I don't think it should, since the discoverability of such content by visitors would be terrible. It is bad user experience. It is much better to design your page so that information that the visitor would want to see is laid out on the top of the page or along one of the margins.
 * So, the hack is not necessary at all. Please please, do not use tables for layout. I will have to reject any suggestion of using tables for layout, since they break so many things. I know of many web designers that would come armed with forks upon me if I start using tables for layout.
 * , Wikilog already supports that. --Juliano 22:28, 23 June 2010 (UTC)
 * Wikilog doesn't offer an easy way to add content after the roll, and I don't think it should, since the discoverability of such content by visitors would be terrible. It is bad user experience. It is much better to design your page so that information that the visitor would want to see is laid out on the top of the page or along one of the margins.
 * So, the hack is not necessary at all. Please please, do not use tables for layout. I will have to reject any suggestion of using tables for layout, since they break so many things. I know of many web designers that would come armed with forks upon me if I start using tables for layout.
 * , Wikilog already supports that. --Juliano 22:28, 23 June 2010 (UTC)


 * Understood. Perhaps what this issue calls for is some simplified instructions in the user documentation.  I was looking at it through the eyes of the end users who don't necessarily know HTML - what's the easiest way for an editor to create the margin?  I had opted for a table solution because there are Wikimedia help files where editors can learn about tables, but not so about  s.  The optimal solution (at least for an editor) would be one where the editor has a separate place to enter the content that he/she wishes to see in the margin, and not have to deal with the coding at all. --PerkinsTaylor 18:56, 24 June 2010 (UTC)


 * In order to use MediaWiki, editors have to know a little of HTML and CSS. This is how MediaWiki works, it does not provide a WYSIWYG editor out of the box, the end-user has to deal with some formatting markup. --Juliano 01:38, 25 June 2010 (UTC)

Creating a Styled Box for Post Summaries
There can be cases where the summary section of a blog post is an abstract for the post, and while it doesn't belong as a part of the article, it should not necessarily be hidden either. For such cases, it would be advantageous to be able to include a "box" parameter available for the  tag that would trigger the summary to be displayed in the post article according to a predefined style.

A hack to create a styled summary box can be found at Extension:Wikilog/Hacks.

--PerkinsTaylor 04:33, 23 June 2010 (UTC)


 * I can see the motivation to style the summary differently in the article page, but I wonder if this would be so common to justify. It is currently possible to achieve similar results with just templates. Create a template that gets the summary text as a parameter and replace it inside the a div box, using.
 * The suggested "box" parameter itself is not the correct approach. It is way too specific for a single situation (what if another user wants a parameter to make the summary text blue?) and it mixes semantic and presentation. It would be more adequate to add a "class" parameter, which would cause Wikilog to add the summary inside a div with the given class. Then it is up to the user to use CSS to render it in a box, in blue text or anything else.
 * , but I can consider a more generic approach. --Juliano 22:28, 23 June 2010 (UTC); edited 18:22, 24 June 2010 (UTC)


 * Here again I was trying to give editors a little more control of the formatting without requiring too much of them. Knowledgable editors will be able to style the text themselves without any help.  What I am looking for is a way to give administrators the means to preset an alternate style that editors could simply toggle on or off. --PerkinsTaylor 18:57, 24 June 2010 (UTC)


 * Even then, it is not correct to make modifications to the code when it is possible to achieve the same result with vanilla Wikilog.
 * --Juliano 01:38, 25 June 2010 (UTC)

Creating Pages with Preloaded Text
It would be helpful to be able to configure the extension to preload new wikilog pages with text from a specific user-defined file and to preload new article pages with text from another user-defined file.

--PerkinsTaylor 04:33, 23 June 2010 (UTC)


 * Please, see Creating pages with preloaded text. There are also many extensions listed there that does this. Just choose one and configure it to preload the text on article pages in the wikilog namespace.
 * , there already are alternatives. --Juliano 22:28, 23 June 2010 (UTC)


 * True, there are extensions that can be used to preload the text for the blog pages. The challenge is that the "passive" preloader extensions (those that do not require an inputbox) seem to fall into one of two categories: those that preload according to namespace and those that preload according to a regex pattern.  The per namespace preloaders aren't applicable because Wikilog users will likely want one preload file for wikilogs and a different one for articles - both of which are in the same namespace.  A per regex pattern preloader would work, but requires users to be able to decipher regex patterns.  My suggestion that preloading features be added to Wikilog is one of economy - while it would require a little additional work on your part, it would save others a lot of head-scratching.  I just thought that you could do something as simple as adding an "if" or "switch" construct in the actionNewItem function that would evaluate whether the new title belonged to the Wikilog namepace(s) and whether it was a wikilog "page" or article "subpage," and then add "&preload=...." to the "action=edit" part of the "$wgOut" statement. --PerkinsTaylor 18:59, 24 June 2010 (UTC)


 * Perhaps, it should be possible. Please register this as a feature request in the issue tracker.
 * --Juliano 01:38, 25 June 2010 (UTC)

Heading Script Consistency
It seems that most of the default Mediawiki skins place the editsetion link of a section heading inside of the  tags, making the heading string. In the SummaryPager, it appears that Wikilog places the editsetion link "before" the  tag.

A hack to make wikilog headings consistent with Mediawiki skins can be found at Extension:Wikilog/Hacks.

--PerkinsTaylor 04:33, 23 June 2010 (UTC)


 * I don't remember why I did it that way (I'm not even sure if I did it intentionally or if it was a mistake), but you are right that it is inconsistent. I'll check and fix it.
 * By the way, again, that code is completely different in the current development version of Wikilog.
 * --Juliano 22:28, 23 June 2010 (UTC)


 * Thanks. Looking forward to it. --PerkinsTaylor 19:03, 24 June 2010 (UTC)


 * ✅ in current dev version. --Juliano 01:38, 25 June 2010 (UTC)

Disable Editsection Links on Wikilog Page
I suspect that there are far more "readers" who inadvertently click the editsection link in the wikilog page than there are "editors" who use the link to go to the article's edit page directly from the wikilog page. Therefore, I prefer not to have the editsection links enabled on the wikilog page. Perhaps there could be a  setting that would allow administators to configure this themselves.

A hack to add a toggle to disable editsection links on the wikilog page can be found at Extension:Wikilog/Hacks.

--PerkinsTaylor 04:33, 23 June 2010 (UTC)


 * This suggestion sort of contradicts the previous one. If it is to keep consistency, removing edit links in wikilog pages would make them inconsistent with the rest of MediaWiki. What I'm actually going to do (soon, probably) is to make Wikilog honor the users 'editsection' preference and the parser keyword. I'd rather keep this as a user preference. You can control default user preferences (which applies to anonymous visitors) via $wgDefaultUserOptions.
 * , however, I'm going to make it honor user preferences. --Juliano 22:28, 23 June 2010 (UTC)


 * Making Wikilog honor the users 'editsection' preference and the parser keyword is the better idea.  I look forward to it. --PerkinsTaylor 19:04, 24 June 2010 (UTC)


 * ✅, partially. Wikilog now honors the user preference and doesn't display edit links if they are disabled. The keyword is a little more difficult because the roll is generated outside the parsing of the wikilog page. I'll consider it later.
 * --Juliano 01:38, 25 June 2010 (UTC)

Inline Rendering of the "Read More" Link
To save space on the wikilog page, I would prefer to be able to place the "read more" link inline at the end of last paragraph of the text block, although I can see why others might want it in a new paragraph. Perhaps there could be a  setting that would allow administators to configure this location themselves.

A hack to add a toggle for inline rendering of the "read more" link can be found at Extension:Wikilog/Hacks.

--PerkinsTaylor 04:33, 23 June 2010 (UTC)


 * I think that this issue is too specific to justify. And the proposed solution is very suboptimal, well... an actual "hack", which isn't good. I can immediately pinpoint a bug in that code that will break upon certain input. And since it is open-source, we have to consider that any vandal (wikis are particularly notable for attracting vandals) will have access to the code and will know how to break it.
 * MediaWiki-parsed wikitext is really not meant to be edited this way. In fact, using regular expressions to parse or alter HTML or XML markup is very wrong. You really shouldn't do this. Just consider this is as a limitation of MediaWiki and live with it. Wikilog gets a block of wikitext that is the summary, uses MediaWiki to parse it, and gets back a fragment of ready-to-render XHTML code.
 * You can, however, disable the read more link by changing the 'wikilog-summary-more' system message (current dev) to just an HTML comment, and it will disappear from the list. Then you can put the read more link in the footer ('wikilog-summary-footer' message).
 * There are at least one way (that I can see) to achieve the result in a "correct" way, but the amount of code necessary to make it work correctly (and the work to maintain this additional code) doesn't justify for something so specific. Sorry.
 * , too specific, causes other problems. --Juliano 00:41, 24 June 2010 (UTC)


 * Is it possible to concatenate the "summary" string and the "more" string before they get their  tags?  In other words, can you place the "more" link right at the end of the "summary" paragraph and then put a   or two in  ?  End users can always add a line feed before the "more" link, but we can't take them out if they are forced by paragraph tags. --PerkinsTaylor 19:04, 24 June 2010 (UTC)


 * Not easily, and not without breaking other things. The summary and the more string come from different directions, are parsed independently and then their resulting HTML fragments are just concatenated. Again, it is better for you to just consider them different pieces.
 * --Juliano 01:38, 25 June 2010 (UTC)

Inputbox Size for the Create New Wikilog Article Form
I've found that the inputbox for the new article name in the create new wikilog article form is smaller than it might be. I'd recommend increasing to 70. It can be changed by altering the following line in WikilogMainPage.php:

$fields[] = Xml::inputLabel( wfMsg( 'wikilog-item-name' ),			'wlItemName', 'wl-item-name', 25 );

--PerkinsTaylor 04:33, 23 June 2010 (UTC)


 * Ok. This is simple and makes sense. Although I think that 70 is too much. Consider that there are people that have very small screens (specially this current wave of netbooks, tablets and phones). I tested with 50, and it provides a good amount of space to write the title comfortably.
 * ✅. --Juliano 00:41, 24 June 2010 (UTC)


 * Thanks. Looking forward to it. --PerkinsTaylor 19:03, 24 June 2010 (UTC)

Tag Listing
It would be beneficial to have a special page or a collection of special pages that created a variety if different lists of tags that are set in the blogs - a list of all tags, a list of articles that do not have tags, most popular tags, etc.

--PerkinsTaylor 04:33, 23 June 2010 (UTC)


 * This is planned functionality. I would like to do it in a sub-extension, and to reuse some code.
 * , but in the long term. --Juliano 00:41, 24 June 2010 (UTC)


 * Thanks. Looking forward to it. --PerkinsTaylor 19:03, 24 June 2010 (UTC)

Multiple Criteria Searches
It would be helpful if the funtionality of the Special:Wikilog page could be expanded to allow unions, intersections and exclusions - "all articles with tag1 AND tag2," "all articles with tag1 OR tag2," "all articles by user1 but NOT with tag2,"  "all articles within a date range,"  "articles that have a specific name," etc.

--PerkinsTaylor 04:33, 23 June 2010 (UTC)


 * This is a really difficult topic. These sort of queries need specialized database indices to be efficient, and performance is a concern I take very seriously in my code. It is for the same reason that MediaWiki itself also doesn't have this feature for categories. It is exactly the same issue with Wikilog tags. There are extensions that list unions of categories, but not any trunk code.
 * So, this will not be done until there is a well-performing way to query for unions and that feature is implemented in MediaWiki itself.
 * , too big of a problem, even MediaWiki didn't fix it yet. --Juliano 00:41, 24 June 2010 (UTC)


 * I figured as much, but thought I'd ask anyway. Thanks for your consderation. --PerkinsTaylor 19:03, 24 June 2010 (UTC)

Eliminate Extraneous "from this wikilog" Text from By-Lines
It seems unnecessary for the by-lines in the wikilog to say "from ..." when you are actually at that wikilog. I'd prefer that the "from this wikilog" only be rendered when readers are at a different page.

A hack to eliminate the extraneous text from the wikilog pages that the articles belong to can be found at Extension:Wikilog/Hacks.

--PerkinsTaylor 04:33, 23 June 2010 (UTC)


 * This was already fixed in the current development version of Wikilog. The entire wikilog page rendering changed a lot. The code cited doesn't even exist anymore.
 * Already ✅ in the current dev. --Juliano 00:41, 24 June 2010 (UTC)


 * Thanks. Looking forward to it. --PerkinsTaylor 19:03, 24 June 2010 (UTC)

search not work for username two words
If your username "John Smith" it write "John Smith" in _wikilog_authors. Special:Wikilog search for "John Smith" not find "John Smith". Special:Wikilog search for "John Smith" find "John_Smith". If your username "John Smith" it need write "John_Smith" in _wikilog_authors.


 * ✅ Thanks! This is fixed in Special:Code/MediaWiki/68810. --Juliano 03:08, 1 July 2010 (UTC)

Search in articles of a specific blog
Hi, Juliano! Your extension is really great!

I've been using it last days at work (this site).

I just like to request a feature: it would be nice if we could search by content in the special:wikilog page, so that it would be possible to get all articles of a specific blog that contain a certain word. Actually this is the feature that we most want in wikilog.

Could you please say me if that is on the way? Maybe I can help you develop that.

--Matheus Garcia 19:18, 29 July 2010 (UTC)


 * Hello Matheus,
 * Thanks! It is good to know that the extension is useful for you.
 * The feature that you request is out of the scope of this extension. Wikilog articles are just subpages of the main wikilog page. So what you need is a search extension that is able to limit searches to subpages of a given page. There is no need to make something specifically for Wikilog.
 * This extension already exists! With Lucene search, you can use prefix:... to limit search to subpages of a given page. For example, to search for posts containing "YYY" in wikilog "XXX", you make the search:
 * YYY prefix:Blog:XXX/
 * See en:Help:Searching for more information and other features of Lucene search, and Extension:Lucene-search and Extension:MWSearch on how to install Lucene search.
 * Hope this helps.
 * P.S.: Do not edit Wikilog tables directly. Your changes to wlp_pubdate are likely to be lost the next time the articles are updated. Instead, change the date in the  tag inserted at the bottom of your posts.
 * Regards,
 * --Juliano 02:00, 30 July 2010 (UTC)


 * That's good, I'll try this Lucene extension!
 * And thanks for your tip with wl-publish, I'll do that too. I was wondering how did you understood the text in the blog, just now I saw in your page that you are brazilian too!
 * Best regards,
 * --Matheus Garcia 00:50, 31 July 2010 (UTC)


 * You are welcome!
 * Best regards,
 * --Juliano 01:10, 31 July 2010 (UTC)

Real user names in blog posts
Hi, Juliano!

In our mediawiki installation we use ldap authentication, but our user names in ldap are all numeric. In each wikilog post there is a line just after the title which says the author, publish date and others, but with this numerical user names it's not easy for us to identify the author.

For other articles, we already have installed Extension:PageHistoryRealnames to show real names in page history. I'd like to have something like that on wikilog, so that it would include the user real name, instead of wiki user name.

With that been said, I'd like to suggest you to allow configuring this on next release of wikilog, if you think you should. I can try doing that by myself if you want.

[], Matheus Garcia19:04, 4 August 2010 (UTC)


 * Hello Matheus,
 * Your installation seems is a little strange. I do not remember how to configure LDAP auth, but I don't think you have to have these numeric user names. If I remember correctly, the LDAP extension had a way to generate a proper username from the LDAP credentials.
 * Anyways, it should be possible to provide this as an option. Note that if this is implemented, it will only change how usernames are displayed. You will still have to use your wiki username to sign your posts, to perform searches based on authors, etc. This may become very confusing for your users. You should really consider looking for a way to fix the LDAP authentication, so that your wiki username is more sensible.
 * Please, post this suggestion as a feature request in the extension issue tracker. It is easier to manage than in this discussion page. Also note that the extension has a mailing list (address at the top of this page).
 * Regards,
 * --Juliano 21:38, 4 August 2010 (UTC)


 * Hi! There's nothing wrong with LDAP, those numeric usernames are really our usernames, they correspond to our registration numbers at work! So we should reaaly appreciate you provide this option, which would at least allow us to see who wrote a blog article.
 * I'll request this feature like you mentioned, and also join the mailing list, because I'm really interested in this extension.
 * -- Matheus Garcia 15:58, 6 August 2010 (UTC)

Thanks for your support Juliano
He answered prompt and what counts: with a working solution. --Erkan Yilmaz 14:44, 14 August 2010 (UTC)