Extension talk:Wikilog/Hacks

After I installed Wikilog, I hacked it to configure the user interface to match the needs of a specific wiki application. Since there are a number of alternatives that other administrators might find beneficial, or if there are features that Juliano may wish to include in future versions of Wikilog, I have started this page where others can share hacks.

--PerkinsTaylor 18:42, 23 June 2010 (UTC)

Hello,

There are 7 "hacks" listed on this page. I already commented on Extension talk:Wikilog, but I'll put my observations here too:

1. Creating Marginalia in a Blog Page:
   • Wikilog already provides enough styles that allow users to create marginalias easily. You can see this in effect at my blog. There really isn't any need to make changes to extension code, just use the correct CSS. Perhaps some better explanation on how to do this on the styling help page, but definitely not keeping this hack.
2. Creating a Styled Box for Post Summaries:
   • This is too specific. It is possible to achieve this with just a template, without changing any code. There is a limitation on expanding template parameters inside tag extensions and it is necessary to use the {{#tag}} parser function.
3. Heading Script Consistency:
   • This is just a bug, and I'm going to fix it in the Wikilog code. No need for the users to use a hack, just upgrade to the next version when it is available.
4. Disable Editsection Links on Wikilog Page:
   • This is a user preference. Currently Wikilog doesn't honor the user preference, but I intend to fix this soon. Wikilog now honors the user preference.
5. Inline Rendering of the "Read More" Link:
   • The suggested hack have problems, and this is a MediaWiki limitation that is difficult to transverse. I really don't recommend. It is better to just accept that things are like this in MediaWiki.
6. Inputbox Size for the Create New Wikilog Article Form:
   • Already fixed in current dev.
7. Eliminate Extraneous "from this wikilog" Text from By-Lines:
   • Already fixed in current dev.

I don't know if it was the intention, but it seems that the page was created to encourage people to copy these code fragments into their copies of the Extension in order to obtain these "features". If this was the case, it causes more problems than it solves. As the primary developer of the extension, I strongly discourage the use of any "hack".

Using this kind of "hacks", the following problems happen:

1. Users are not developers. If some problem arise from the use of the code copied from this page (a version incompatibility, some use-case that was not expected, etc), they will not be able to understand what is causing the problem and fix it. They will end asking for support to the actual developers (me in this case), who will have to spend time trying to understand and fix a problem that are not their own. I have experienced this many times myself. If you want to work in the code, great! You are welcome! But please do not encourage people who are not developers to alter code blindly.
2. There will always be a new version. I keep working on the extension when I can, the code evolves little by little. The hacks suggested in this page are based on a code that is not the current development version. So the code in these hacks will not be the same in the next version. If the user keeps using these hacks, they will be using obsolescent features.
3. Custom code breaks upgrades. Many things listed here are radically different in the next version of Wikilog, and so the code is incompatible. It becomes a burden to the user to upgrade these hacks every time they upgrade the extension. Some users choose to stay using old versions just because they did a lot of changes to the code that are no longer valid in new versions.

The existence of "hacks" is usually the result of one or more of these:

1. There is a problem in the software: in this case, you should report a bug to the developers or make a patch against the current dev version and send to the developers. The developers will review the patch (they are working with the code much longer than other people, they are more qualified to see if nothing is really missing, or if the fix is correct), apply it and then release a new version of the software. Users just upgrade to the new version and problem resolved. No need to copy/paste any hack.
2. You have a specific requirement that is valid but not general enough to justify: in this case, the developers may add hooks or API to the code so that that requirement can be implemented through a script, plugin or extension. This is the case of Wikilog itself. MediaWiki is a wiki, it does not justify to add blogging features to it, but MediaWiki provides all the API and the hooks that enabled the creation of Wikilog as an extension.
3. You have some requirement that is simply not compatible with the software: in this case, the developers may not be interested with that requirement, and your option is to fork the project and maintain the features you need. In this case, any change you make is your responsibility.

Note that there is no reason to keep any "hack" around given the tree situations above. I know that you had good intention and that you spent a lot of time compiling this list of hacks, creating and writing this page (I also spent a few hours replying all of this), but I really think that there is no reason to maintain this list of hacks, on the contrary, it may even bring more work given the problems described above.

I hope you understand.

Best regards,

--Juliano 03:02, 24 June 2010 (UTC); edited 18:28, 24 June 2010 (UTC)