Extension talk:Wikilog/2009

From mediawiki.org
Jump to navigation Jump to search

WikiLog Review[edit]

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.[edit]

I can create and access the blog tab and page but:

  1. When I try to access the Wikilog Tab I'm getting:
    • 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:
    • 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 — Preceding unsigned comment added by (talkcontribs)


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 -- 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 Category: 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 Special:Wikilog 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):
{{wl-tags: Tag 1 | Tag 2 | Tag 3 ... }}
To search for posts with a given tag: [[Special:Wikilog/tag=<tagname>]] .
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)


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/

— Preceding unsigned comment added by Daniel K. Schneider (talkcontribs)

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 [[Template:WikilogTemplate1]], with the following contents:
<div class="{{{class}}}">
2. Add this code to the page you want to include the blog contents (change <blogname> to the name of your wikilog):
This includes the list of articles of your wikilog, using the template specified ([[Template:WikilogTemplate1]]), 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. -- 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 {{{hasMore}}}, 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...-- 08:13, 3 November 2009 (UTC)
f.e. this <summary>Neues Projekt gestartet. Details gibts hier: [[Libraries für PLC Programme]]</summary> {{wl-publish: 2009-10-30 13:19:50 +0100 | Zec }} has the {{{hasMore}}} set. Or does your routine recognize the signature as "more"? This would be very bad...
Yes, it is supposed to behave like this. Using <summary>...</summary> 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: {{#if: {{{hasMore}}} | '''[[{{{page}}}|→ mehr...]]''' <br> | gibt net mehr...}} always returns the [[{{{page}}}|→ 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... -- 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 {{wl-publish:...}} in the same line as the text in the article, and remove the newline after {{{summary}}} in the template, these extra lines disappear. E.g.:




{{{summary}}}{{#if: {{{hasMore}}} | ...
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[edit]

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''


</noinclude><includeonly><div class="{{{class}}}">[[{{{page}}}|'''{{{title}}}''']]
<br />— by {{{authors}}} - {{{pubdate}}}<br />{{{summary}}}</div></includeonly>

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

This template allows to include blog entries from a wikilog (bliki). It will list all items that you could include with a "Wikilog template".

;Syntax of use:

:_blogname_ = Name of your Blog, e.g. DKS
:_Wikilogtemplate_ = Name of the template, e.g. BlikiTitlePageTemplate
:5 = number of items to display

;Additional hints
: You can use the <nowiki><summary>...</summary></nowiki> to define what goes into the body of the entry. By default (as of v. 0.7.2) this extension will take all text before a title "==...==" or else the full text.
: Install this template for testing :)

The template "includeonly" code has been defined as follows (look at the source):
	<li>'class' = {{{class}}}</li>
	<li>'wikilogTitle' = {{{wikilogTitle}}}</li> 
	<li>'wikilogPage' = {{{wikilogPage}}}</li>  
	<li>'title' = {{{title}}}</li>
	<li>'page' = {{{page}}}</li>
	<li>'authors' = {{{authors}}}</li>
	<li>'tags' = {{{tags}}}</li>
	<li>'published' = {{{published}}}</li>
	<li>'pubdate' = {{{pubdate}}}</li>
	<li>'updated' = {{{updated}}}</li>
	<li>'summary' = {{{summary}}}</li>
	<li>'comments' = {{{comments}}}</li>
<hr />
<hr />
	<li>'class' = {{{class}}}</li>
	<li>'wikilogTitle' = {{{wikilogTitle}}}</li> 
	<li>'wikilogPage' = {{{wikilogPage}}}</li>  
	<li>'title' = {{{title}}}</li>
	<li>'page' = {{{page}}}</li>
	<li>'authors' = {{{authors}}}</li>
	<li>'tags' = {{{tags}}}</li>
	<li>'published' = {{{published}}}</li>
	<li>'pubdate' = {{{pubdate}}}</li>
	<li>'updated' = {{{updated}}}</li>
	<li>'summary' = {{{summary}}}</li>
	<li>'comments' = {{{comments}}}</li>
<hr />

- 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[edit]

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:

== Bliki testing ==


== New testing ==

I get this:


    * 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[edit]

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.

HeaderTabs Screenshot.jpg

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.
--Juliano 14:38, 2 September 2009 (UTC)
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)[edit]

Currently (v 0.7) it is possible to rename a post but the title of the post remains the same. E.g.


will rename to


but the title stays, e.g.

 <h1 id="firstHeading" class="firstHeading">Table PCs</h1>

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)
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)
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[edit]

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.
--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[edit]

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 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)
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)[edit]

The fix that you made to 0.7.3 is not in 0.8.0. See discussion above:

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.
--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[edit]

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) 13:24, 28 October 2009 (UTC)!

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
-- 12:35, 29 October 2009 (UTC)
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.
--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
-- 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 :)
-- 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?[edit]

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?

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

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?
--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?
-- 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 {{wl-info:all-namespaces}} 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. -- 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[edit]

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)