Extension talk:Wikilog/2010

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:

{{Special:Wikilog/Quotes:Character quotes/Category:Quotes by XXX/5}}

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)

Is this fix only available in the trunk, or can I use the REL1_16_0 tag version? --Enterprise user 22:26, 7 January 2011 (UTC)

No, it is not included in REL1_16_0. It is in REL1_16_1 and the REL1_16 branch.

--Juliano 06:10, 8 January 2011 (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)

it's a good idea!Please make it quickly,I want to use it now !--Iwikia 01:27, 14 January 2011 (UTC)

Quickly? No. Nobody pays me to develop Wikilog and I do not receive donations; I do it in my free time. This feature is out of the main scope of the extension, and has lower priority. It is in the list of things to consider, but I'll do it when I'm able to. You are welcome to contribute the needed code yourself, or hire someone to write it. --Juliano 14:06, 17 January 2011 (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:

1. This kind of discussion is better suited for the mailing list, since it is easier to send patches and discuss the changes.
2. 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.
3. 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:

 

div.wl-wrapper { overflow: hidden; }

 

This will allow any box to float and flow along the margins of the roll. Just create a <div style="clear:right; float:right; width:10em;">...</div> 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.

N Not done, 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 <div>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 <summary> 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 {{#tag:summary|{{{1}}}}}}.

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.

N Not done, 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.

N Not done, 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 <h2> ... </h2> tags, making the heading string <h2> [editsection link] [section heading title] </h2>. In the SummaryPager, it appears that Wikilog places the editsetion link "before" the <h2> 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.

In progress --Juliano 22:28, 23 June 2010 (UTC)

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

 Done 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 $wgWikilogAllowRollEdit 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 __NOEDITSECTION__ parser keyword. I'd rather keep this as a user preference. You can control default user preferences (which applies to anonymous visitors) via $wgDefaultUserOptions.

N Not done, 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 __NOEDITSECTION__ parser keyword is the better idea. I look forward to it. --PerkinsTaylor 19:04, 24 June 2010 (UTC)

 Done, 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 $wgWikilogMoreInline 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.

N Not done, 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 <p> ... </p> tags? In other words, can you place the "more" link right at the end of the "summary" paragraph and then put a <br> or two in wikilog-item-more? 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.

 Done. --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.

In progress, 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.

N Not done, 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  Done 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.

 Done 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#Search engine features 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 {{wl-publish:...}} 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)

Alternative installation?

I'd really love to get this extension going.. however my host has a draconian policy on having to pay for ssh access.. which means I can't run mediawiki's update.php without having to pay for the privilege.

Suggested options are to of course delete or rename localsettings.php and then running the installer.. and as you can imagine this also means that wikilog's setup is skipped..

Is there an alternative anyone is aware of for setting up the SQL tables? any help is much appreciated

--Jamietelford 12:06, 14 September 2010 (UTC)

Hello,

MediaWiki needs shell access in order to run a lot of administrative tasks. If your host doesn't provide shell access, it is not really suitable for MediaWiki. This is not a Wikilog problem. You will have problems later, every time you need to do any maintenance task.

Anyways, rerunning the installer should be equivalent to running the update script.

Refer to the following pages for more information:

* Manual:Upgrading#Alternative 1: phpShell

* Manual:Upgrading#Alternative 2: Re-run the installer

* Manual:FAQ#Does MediaWiki require shell access?

--Juliano 19:04, 14 September 2010 (UTC)

ok.. after playing around some more I've got phpShell up and running and executed update.php as suggested..

i get the following from my installation on save edit

• from within function "WikilogLinksUpdate::getExistingAuthors". MySQL returned error "1146: Table 'wiki2.wikilog_authors' doesn't exist (localhost)".

so is the update.php supposed to do some updates to the sql database?

--Jamietelford 06:31, 16 September 2010 (UTC)

It looks like either update.php failed to update the database (you must check the messages returned from update.php, specially the last 10-20 lines), or update.php was executed before the include line was added to LocalSettings.php.

Rerun update.php and paste here the last 10-20 lines of output.

Regards, -- Juliano 16:38, 16 September 2010 (UTC)

Well first off... Thanks for all the help Juliano!

My solution in the end is as follows

1. upload wikilog extension
2. modify localsettings.php
3. run phpMyAdmin and manually import wikilog-tables.sql into sql database for wiki
4. force the creation of page by accessing through wiki Blog:Blog&action=wikilog
5. all is working

so in finshing you can also do the above as an installation and as far as I can tell don't need to bugger around with running the update.php maintenance script..

next for me is figuring out how to hide the 'blog' tab and move the RSS feed link somewhere other than the toolbox..

cheers! --Jamietelford 01:12, 17 September 2010 (UTC)

Parse error: syntax error, WikilogUtils.php on line 100

looks like a great extension, but i haven't been able to get it running yet...

first off, all the documentation implies the new namespace is Wikilog. It's pretty obviously Blog which makes more sense but confused me for a bit. second, none of the docs seemed to mention that ?action=wikilog was required. i see no other way to add a page.

but most of all... when i try that action, i get an empty page with: Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in /home/username/public_html/extensions/Wikilog/WikilogUtils.php on line 100

if i add a page in Blog namespace using the standard action=edit i just get a normal wikipage. weird

thanks for your efforts in writing this extension. seems like the best blogging setup for mw. this was actually me, not anon. wikimedia logged me out again...

- Oo.et.oO 03:38, 6 December 2010 (UTC)

Hello,

The very same question was asked recently in the extension mailing list (was it you?), to which I replied asking for information about the versions of PHP, MediaWiki and Wikilog, and no answer was sent back. Without this information, it is difficult to provide any help. Most likely, you have an old version of PHP.

The documentation is dynamic, and varies according to the site it is installed. In the official documentation wiki, the Wikilog namespace is "Wikilog". When you install the documentation in your wiki, it will reflect the correct namespace chosen on your wiki.

?action=wikilog is passed automatically when you click the "Wikilog" tab after creating a wikilog.

Regards,

--Juliano 19:27, 6 December 2010 (UTC)

thanks for your reply Juliano. twas not myself who emailed the list

MediaWiki 1.16.0

PHP 5.2.10 (cgi)

MySQL 5.0.91-community

i use the docs that are linked to from this content page http://wiki.juliano.info/wiki/Help:Wikilog . why do those docs say ns is "wikilog" if the default/install docs says "blog"? what's the required php version? i see no required php version in the content of this extension page, perhaps it should be added.

not sure why this watched page didn't email me. i'll keep checking back...

--Oo.et.oO 03:22, 10 December 2010 (UTC)

The problem you are seeing is result of a recent change to the extension on trunk. I used a feature of PHP that is only available in PHP 5.3. For now, please, revert to a stable version of Wikilog (1.1.0), which doesn't have the code.

"Wikilog" is not a default namespace, this is not affirmed anywhere. The particular wiki where the documentation is hosted uses "Wikilog" as its namespace for wikilog articles, and this reflects in the documentation when it is read there. The documentation is dynamic. When you install the documentation in your wiki, it will show the correct namespace in your wiki.

Regards,

--Juliano 13:49, 11 December 2010 (UTC)

Had the same parse error and reverting to the stable 1.1.0 seems to of resolved any issues I was having. Will future releases require PHP5.3? --Enterprise user 19:09, 7 January 2011 (UTC)

No, the requirements of Wikilog should be the same of MediaWiki itself (except that Wikilog requires a MySQL DB, support for other databases will be added in the future). The change in question will be reversed before the next stable release, to keep compatibility with PHP 5.2. --Juliano 19:22, 7 January 2011 (UTC)

Can you please fix this problem soon? I am also having this issue, my client has PHP 5.2 installed, with not much chance to go to 5.3 for a while, and I would like my client to be on the current level of your code. They like alot your extension. Thanks very much... --65.117.229.105 20:44, 9 February 2011 (UTC)

Please, do not use trunk versions in production code. The trunk/development of Wikilog (also valid for MediaWiki and almost all other open-source software around) is not intended for production use. It is intended only for developer use. Things break in a regular basis. Please, use the stable version (currently 1.1.0).

The bug should be fixed now in r81929. Please, check and report.

--Juliano 03:19, 11 February 2011 (UTC)