You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm trying out shortcodes-core v5.2.0 and it appears that default shortcode classes load assets from the handler function, i.e. each time it is called to process the shortcode on a page. E.g. in FontAwesomeShortcode there is:
This is ineffective and also may lead to problems with processing shortcodes in certain situations. One such situation is the default error page of the Quark theme. If I add a shortcode to the default footer.html.twig template using this form:
{{ '[fa=grav extras=fab/]'|shortcodes|raw }}
then the icon won't display because fontawesome.css (whatever is configured in plugins.shortcode-core.fontawesome.url) is not loaded on the page Grav generates as a result of accessing an invalid URL on the web site (basically, a default grav-admin-v1.7.46 installation). Please note that in order to reproduce the problem you need to remove loading Grav-supplied FontAwesome from stylesheets block of the default Quark's base.html.twig template (or the icon will come from there, of course).
It's worth mentioning that the shortcode itself is handled fine in this place using the shortcode Twig filter. I.e. I get
<iclass="fab fa-grav"></i>
in the resulting page's HTML. It's only that fontawesome.css is not there, so the browser doesn't know where to get fab and fa-grav styles from and displays nothing.
If I move the addAssets call out of the handler function to the init function like this:
then all starts to work smoothly — the CSS is there and the icon "magically" appears.
I'm not a PHP/Twig/Grav expert but I guess the reason is that by the time when the handler function is executed while generating the error page, its assets are already processed by Grav so addAssets has no effect. It's not the case with the init call because it seems to be called somewhere at the very beginning, so the CSS asset is correctly added to every involved page.
And as I mentioned before, it really makes no sense to call addAssets each time the shortcode gets processed. It's a meaningless waste of resources.
Grepping in /user/plugins/shortcode-core/classes/shortcodes for addAssets shows that SafeEmailShortcode.php and NoticeShortcode.php suffer from exactly the same problem. Asset loading should be done once and init itself is a perfect place for that IMO.
The text was updated successfully, but these errors were encountered:
I'm trying out
shortcodes-core
v5.2.0 and it appears that default shortcode classes load assets from the handler function, i.e. each time it is called to process the shortcode on a page. E.g. inFontAwesomeShortcode
there is:grav-plugin-shortcode-core/classes/shortcodes/FontAwesomeShortcode.php
Lines 11 to 15 in dc33833
This is ineffective and also may lead to problems with processing shortcodes in certain situations. One such situation is the default error page of the Quark theme. If I add a shortcode to the default
footer.html.twig
template using this form:then the icon won't display because
fontawesome.css
(whatever is configured inplugins.shortcode-core.fontawesome.url
) is not loaded on the page Grav generates as a result of accessing an invalid URL on the web site (basically, a defaultgrav-admin-v1.7.46
installation). Please note that in order to reproduce the problem you need to remove loading Grav-supplied FontAwesome fromstylesheets
block of the default Quark'sbase.html.twig
template (or the icon will come from there, of course).It's worth mentioning that the shortcode itself is handled fine in this place using the
shortcode
Twig filter. I.e. I getin the resulting page's HTML. It's only that
fontawesome.css
is not there, so the browser doesn't know where to getfab
andfa-grav
styles from and displays nothing.If I move the
addAssets
call out of the handler function to theinit
function like this:then all starts to work smoothly — the CSS is there and the icon "magically" appears.
I'm not a PHP/Twig/Grav expert but I guess the reason is that by the time when the handler function is executed while generating the error page, its assets are already processed by Grav so
addAssets
has no effect. It's not the case with theinit
call because it seems to be called somewhere at the very beginning, so the CSS asset is correctly added to every involved page.And as I mentioned before, it really makes no sense to call
addAssets
each time the shortcode gets processed. It's a meaningless waste of resources.Grepping in
/user/plugins/shortcode-core/classes/shortcodes
foraddAssets
shows thatSafeEmailShortcode.php
andNoticeShortcode.php
suffer from exactly the same problem. Asset loading should be done once andinit
itself is a perfect place for that IMO.The text was updated successfully, but these errors were encountered: