Addshore

It's a blog

Month: June 2015

Letting a Joomla component assign View Levels to Users

So I recently came across an issue with my speedy rewrite of the component that is used to power the SWA website. Here is a quick summary of the issue and how I went about fixing it!

The rewrite maintains information about users and members in tables that it has created. A User, in Joomla terms is not the same as a member of the component. Members of the component should be able to access various different menu items depending on various details of their member profile. Thus extra levels of access for users needs to be decided by the component.

Component defined view levels

At the lowest level access to menu items generally depends on what view levels a user has access to. These are stored in the ‘viewlevels’ table, so my component would need to add some view levels in order to do anything here at all.

To do this I added the following to the install.sql file for my component, meaning these 2 view levels would be added if they did not previously exist (I could probably also do this separately in PHP post installation).

Now that the view levels exist menu items can be set to require them. Lovely, except for the fact that I am not going to assign these view levels to users directly, thus right now no one can view these menu items!

Component decided view levels

As my main concern was hiding / showing menu items the logical place to start looking was in ‘mod_menu’ which creates the menus in Joomla. As the module was very small it was easy to see that the list of menu items was generated using the code below.

This method then gets a list of authorised view levels for the current user using the code below:

So of course next we look at JUser::getAuthorisedViewLevels. This method provides some level of caching so that the view levels are only retrieved once per request, meaning less DB casll. But essentially this method gets the view levels from JAccess::getAuthorisedViewLevels. So this is where need a new event!

JAccess::getAuthorisedViewLevels requests all of the view levels currently defined in Joomla as well as all of the groups that the current user is in. A quick look over everything then results in an array of view levels that are assigned to the users groups. This is where we pounce!

Just before the return of this method we add our event:

This passes off the array of view levels to subscribers of the onJAccessGetAuthorisedViewLevels event which means that extra view levels can be added according to $userId.

Note that before this event is fired the code imports all plugins of the group ‘swa’ which is where the plugin that we want to subscribe is located! Also note that the import plugin call is wrapped in an IF so that it is only ever called once, this is due to a loop as apparently the importPlugin method calls the this method again (at some point).

We can then use this event to do whatever we want. See what I did at https://github.com/SWAuk/plg_swa_viewlevels/blob/3c78b858c34f4ee5c3a303b05979191847261837/src/viewlevels.php#L19

Final thoughts

There may have been a nicer way to do this but right now I simply do not have the time!

This is a bit of a hack as we are having to change Joomla code by adding an event however it is a very maintainable hack (simply adding the trigger before a method return).

I wonder if I will ever have time to revisit this….

Review of the big Interwiki link migration

Wikidata was launched on 30 October 2012 and was the first new project of the Wikimedia Foundation since 2006. The first phase enabled items to be created and filled with basic information: a label – a name or title, aliases – alternative terms for the label, a description, and links to articles about the topic in all the various language editions of Wikipedia.

On 14 January 2013, the Hungarian Wikipedia became the first to enable the provision of interlanguage links via Wikidata. This functionality was slowly enabled on more sites until it was enabled on all Wikipedias on the 6th March.

The side bar that these interlanguage links are used to generate can be seen to the right. Continue reading

Wikidata Map – 19 months on

The last Wikidata map generation, as last discussed here and as originally created by Denny Vrandečić was on the 7th of November 2013. Recently I have started rewriting the code that generates the maps, stored on github, and boom, a new map!

The old code

The old version of the wikidata-analysis repo, which generated the maps (along with other things) was terribly inefficient. The whole task of analysing the dump and generating data for various visualisations was tied together using a bash script which ran multiple python scripts in turn.

  • The script took somewhere between 6 and 12 hours to run.
  • At some points this script needed over 6GB of memory to run. And this was running when Wikidata was much smaller, this probably wouldn’t even run any more.
  • All of the code was hard to read, follow and understand.
  • The code was not maintained and thus didn’t actually run any more.

The Rewrite

The initial code that generated the map can mainly be found in the following two repositories which were included as sub-modules into the main repo:

The code worked on the Mediawiki page dumps for Wikidata and relied on the internal representation of Wikidata items and thus as this changed everything broke.

The wda repository pointed toward the Wikidata-Toolkit which is written in Java and is actively maintained, and thus the rewrite began! The rewrite is much faster, easily understood and easily expandable (maybe I will make another post about it once it is done)!

The change to the map in 19 months

Unfortunately according to the settings of my blog currently I can not upload the 2 versions of the map so will instead link to the the twitter post announcing the new map as well as the images used there (not full size).

The tweet can be found here.

Wikidata map 7 Nov 2013

Wikidata map 3 June 2015

As you an see, the bottom map contains MORE DOTS! Yay!

Still to do

  • Stop the rewrite of the dump analyser using somewhere between 1 and 2GB ram.
    • Problem: Currently the rewrite takes the data it wants and collects it in a Java JSON object writing to disk at the end of the entire dump has been read. Because of this lots of data ends up in this JSON object and thus in memory, and as we analyse things more this problem is only going to get worse.
    • Solution: Write all data we want directly to disk. After the dump has fully been analysed read all of these output files individually and put them in the format we want (probably JSON).
  • Make all of the analysis run whenever a new JSON dump is available!
  • Keep all of the old data that is generated! This will mean we will be able to look at past maps. Previously the maps were overwritten every day.
  • Fix the interactive map!
    • Problem: Due to the large amount of data that is now loaded (compared with then the interactive map last worked 19 months ago) the interactive map crashes all browsers that try to load it.
    • Solution: Optimise the JS code for the interactive map!
  • Add more data to the interactive map! (of course once the task above is done)

Maps Maps Maps!

© 2017 Addshore

Theme by Anders NorenUp ↑