Better support for 3rd party blocktype icons in Mahara 15.10+

Bug #1510421 reported by Aaron Wells
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mahara
Fix Released
High
Aaron Wells
15.10
Fix Released
High
Aaron Wells

Bug Description

As discussed in the Mahara dev meeting. With the new bootstrap themes, Mahara core blocktypes now use fontawesome for their icons. Consequently the template that displays each block in the block picker, is no longer using the old thumb.png or get_icon() mtehods to get the block's icon and display it. Instead, it just has a <span> with a class "icon-{blocktype.name}":

https://git.mahara.org/mahara/mahara/blob/master/htdocs/theme/raw/templates/view/blocktypelist.tpl

These are then mapped to fontawesome classes here:

https://git.mahara.org/mahara/mahara/blob/master/htdocs/theme/raw/sass/typography/_icons.scss#L21

It would make sense for us to support the old methods, and we could make the system do this automatically, with some logic in blocktypelist.tpl and/or in htdocs/blocktype/lib.php

Aaron Wells (u-aaronw)
Changed in mahara:
status: New → In Progress
Revision history for this message
Gregor Anželj (gregor-anzelj) wrote :

The workaround only works if page already conains a block of that type. If the block is not present (e.g. when creating empty/blank page) the icon will still not be visible.

Revision history for this message
Aaron Wells (u-aaronw) wrote :
Revision history for this message
Aaron Wells (u-aaronw) wrote :

The patch will automatically look for the old "thumb.png" file, so it should be automatically compatible with block plugins that haven't been upgraded for 15.10.

It also provides 3rd-party developers with the option to name a specific FontAwesome icon they want to use for their block.

The easiest way to test it, is to install a 3rd-party plugin using the old & the new method. I've updated my Clippy blocktype with a couple of branches for this purpose:

Clippy with the "legacy" thumb.png: https://github.com/agwells/maharacontrib-blocktype-clippy/archive/Bug1510421-thumbnail.zip

Clippy with a FontAwesome icon (a paperclip): https://github.com/agwells/maharacontrib-blocktype-clippy/archive/Bug1510421-fontawesome.zip

To test:

1. Install Mahara
2. Download the clippy plugin with the legacy thumbnail, and install it into htdocs/blocktype/clippy
3. Go to the admin screen and install the clippy plugin
4. Log in to Mahara and edit a page. Look for the clippy icon in the "General" blocks category. You should see the small, in-color Clippy icon.
5. Delete the contents from htdocs/blocktype/clippy and replace them with the version of clippy with a FontAwesome icon
6. Log back in to Mahara and edit a page. Look for the clippy icon in the "General" blocks category. You should see a black-and-white FontAwesome paperclip icon.

Revision history for this message
Mahara Bot (dev-mahara) wrote : A change has been merged

Reviewed: https://reviews.mahara.org/5762
Committed: https://git.mahara.org/mahara/mahara/commit/4f849ed2e47001190d46c3293863ab84f991bd08
Submitter: Robert Lyon (<email address hidden>)
Branch: master

commit 4f849ed2e47001190d46c3293863ab84f991bd08
Author: Aaron Wells <email address hidden>
Date: Mon Nov 23 19:19:22 2015 +1300

Display icons for 3rd-party blocktypes plugins

Bug 1510421

Defines a new static PluginBlocktype method, get_css_icon(), which
fetches the name of the CSS icon to use for this blocktype. It returns
false by default, which tells the theme to "fall back" to the old
thumbnail.png instead. 3rd-party plugins can override this to
specify a particular icon to use.

All the core blocktypes have been refactored to extend
MaharaCoreBlocktype, which uses the blocktype name as the name
of the CSS icon to use. I also deprecated the "SystemBlocktype"
class while I was at it.

PluginBlocktype::get_blocktypes_for_category() now returns both
the results of get_css_icon() and the thumbnail.png path, so that
themes can decide which they want to use. (And of course
thumbnail.png is served via thumbnail.php, so 3rd party themes
can provide their own custom image files if they wish.)

behatnotneeded: Requires installing third-party plugins to test

Change-Id: Idb1ecfc7b21175913708e695788906c11133b0c0

Revision history for this message
Mahara Bot (dev-mahara) wrote : A patch has been submitted for review

Patch for "15.10_STABLE" branch: https://reviews.mahara.org/5766

Revision history for this message
Mahara Bot (dev-mahara) wrote : A change has been merged

Reviewed: https://reviews.mahara.org/5766
Committed: https://git.mahara.org/mahara/mahara/commit/2565f2d840a6617d4e3474cbabcb0d21ca5f5434
Submitter: Robert Lyon (<email address hidden>)
Branch: 15.10_STABLE

commit 2565f2d840a6617d4e3474cbabcb0d21ca5f5434
Author: Aaron Wells <email address hidden>
Date: Mon Nov 23 19:19:22 2015 +1300

Display icons for 3rd-party blocktypes plugins

Bug 1510421

Defines a new static PluginBlocktype method, get_css_icon(), which
fetches the name of the CSS icon to use for this blocktype. It returns
false by default, which tells the theme to "fall back" to the old
thumbnail.png instead. 3rd-party plugins can override this to
specify a particular icon to use.

All the core blocktypes have been refactored to extend
MaharaCoreBlocktype, which uses the blocktype name as the name
of the CSS icon to use. I also deprecated the "SystemBlocktype"
class while I was at it.

PluginBlocktype::get_blocktypes_for_category() now returns both
the results of get_css_icon() and the thumbnail.png path, so that
themes can decide which they want to use. (And of course
thumbnail.png is served via thumbnail.php, so 3rd party themes
can provide their own custom image files if they wish.)

behatnotneeded: Requires installing third-party plugins to test

Change-Id: Idb1ecfc7b21175913708e695788906c11133b0c0
(cherry picked from commit 4f849ed2e47001190d46c3293863ab84f991bd08)

Aaron Wells (u-aaronw)
description: updated
no longer affects: mahara/16.04
Changed in mahara:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.