Using bootstrop glyphicon with C5

The following three lines of code...
<span class="glyphicon glyphicon-calendar"></span>
<span class="glyphicon glyphicon-calendar"></span>
<span class="glyphicon glyphicon-plus"></span>

... result in the following errors:
chart:1235 GET net::ERR_ABORTED 404 (Not Found)
chart:1265 GET net::ERR_ABORTED 404 (Not Found)
chart:1 GET 404 (Not Found)

The three lines referenced by the above three errors are:
chart:1235 => <script type="text/javascript" src="//"></script>
chart:1265 => <script type="text/javascript" src="/index.php/ccm/assets/localization/core/js"></script>
chart:1 => <!DOCTYPE html>

What is causing this and how is it prevented?

View Replies:
JohntheFish replied on at Permalink Reply
Not sure if these are the only issues.
- c5 uses a custom build of jQueryUI (its a historical thing to do with dialog modals), so pulling it in from elsewhere can often break things.
- /concrete/fonts does not exist, its /concrete/css/fonts
NotionCommotion replied on at Permalink Reply
Thanks John,

I've been having issues getting jQueryUI to work properly using the shipped versions of jQuery and jQueryUI and was getting "Cannot read property 'dialog' of undefined" errors. It comes with jQuery v1.12.4 and jQuery UI v1.11.4. Have you had any issues? Because of this and also concerns that these older versions might not work nicely with other 3rd party libraries, I used requireAsset() to modify my install to use jQuery v3.4.1 and jQuery UI v1.12.1. I could now use dialogs, but for some reason they are not chainable (i.e. $('#bla').dialog(); doesn't return $('#bla') ) and also the CSS is a little messed up and they don't have a border. Your comment that C5 needing a custom build of jQueryUI also concerns me. Recommend going back to the old version? If so, what needs to be changed to get dialogs working?

Good catch. You are right, /concrete/fonts does not exist. What's funny is I just cut and pasted from the page source and don't think I accidentally deleted "css", but it also seems unlikely that C5 would randomly change this. Also, now Chrome inspector lists these three lines as being the culprit.

<script type="text/javascript">$(function() { ConcreteToolbar.start(); });</script>
<script type="text/javascript" src="/concrete/js/jquery-ui-touch-punch.js?ccm_nocache=ca17add95b11d1baf3d74fcd3fa4637fb02c14ba"></script>
<script type="text/javascript" src="/concrete/js/backbone.js?ccm_nocache=ca17add95b11d1baf3d74fcd3fa4637fb02c14ba"></script>
JohntheFish replied on at Permalink Reply
AFAIK, the UI adaptations are to do with keeping it compatible with dialog modals. The core started way back with an ajax dialog modal that did a lot more than the standard UI dialog. The UI dialog is now wrapped by the core, so sequence of assets is important or you get undefined errors.

Using later versions of jQuery or UI risks compatibility issues with the core or anything that uses the core assets.

Other UI themes can be loaded in addition as long as they are the right UI version and scoped within the page (so they don't get picked up by the core), which you can do with theme roller.

Or, if you have a bootstrap theme, use a popover.
NotionCommotion replied on at Permalink Reply
Ah, just created a new c5 site using the default jquery/jqueryui and added module using $('#dialog').dialog('open');, and got an error (I think it was PNotify related but didn't pay attention), and then found that I need to use the ConcreteAlert wrapper. The notifications look nice, but the dialog and confirm definitely need help. Also, I often use dialogs for forms. I didn't see on whether this is possible. I personally would rather ditch the ConcreteAlert wrapper and use newer versions of jquery/jqueryui (which do allow standard dialog creation), but need to be aware of what other issues might arise. Any thoughts? Thanks
JohntheFish replied on at Permalink Reply
I have used regular UI dialogs without c5 alert in v8. Have a look for core uses, and back through the 5.6 docs/howtos if there is not enough info in v8 docs. It hasn't changed much.

You may also be able to pick up some guidance by looking inside the c5 alert/confirm code.
NotionCommotion replied on at Permalink Reply
You are right (for the most part). If the dialog is opened on click unlike the following, it works. The style, however, seems to have been stripped away. If like the following, one gets the following error. Also, it is not chainable. Not deal breakers, but deviations from how the standard jQueryUI dialog works. Thanks
var dialog = $("#dialog").dialog("open");   //dialog is undefined
jquery.js?ccm_nocache=ca17add95b11d1baf3d74fcd3fa4637fb02c14ba:2 Uncaught Error: cannot call methods on jqdialog prior to initialization; attempted to call method 'open'
    at Function.error (jquery.js?ccm_nocache=ca17add95b11d1baf3d74fcd3fa4637fb02c14ba:2)
    at HTMLDivElement.<anonymous> (jquery-ui.js?ccm_nocache=ca17add95b11d1baf3d74fcd3fa4637fb02c14ba:6)
    at Function.each (jquery.js?ccm_nocache=ca17add95b11d1baf3d74fcd3fa4637fb02c14ba:2)
    at n.fn.init.each (jquery.js?ccm_nocache=ca17add95b11d1baf3d74fcd3fa4637fb02c14ba:2)
    at n.fn.init.e.fn.<computed> [as jqdialog] (jquery-ui.js?ccm_nocache=ca17add95b11d1baf3d74fcd3fa4637fb02c14ba:6)
    at n.fn.init.$.fn.dialog (app.js?ccm_nocache=ca17add95b11d1baf3d74fcd3fa4637fb02c14ba:3)
    at HTMLDocument.<anonymous> (dialog:93)
    at i (jquery.js?ccm_nocache=ca17add95b11d1baf3d74fcd3fa4637fb02c14ba:2)
    at Object.fireWith [as resolveWith] (jquery.js?ccm_nocache=ca17add95b11d1baf3d74fcd3fa4637fb02c14ba:2)
    at Function.ready (jquery.js?ccm_nocache=ca17add95b11d1baf3d74fcd3fa4637fb02c14ba:2)
NotionCommotion replied on at Permalink Reply
Still had an error, but found that it was because the shipped jqueryui doesn't come with autocomplete. Added it separate and no problem.

But, I am still getting the original bootstrop glyphicon errors. Only happens if the page uses bootstraop datepicker and attempts to request content from /concrete/fonts/ which as you pointed out doesn't exist. Chrome inspector doesn't seem to really identify the correct files and is kind of random.
NotionCommotion replied on at Permalink Reply
per JohnTheFish
/concrete/fonts does not exist, its /concrete/css/fonts

Again, you are right. But I don't think it is me, but a bug in C5. To demonstrate, I just created a brand new C5 site, and added a single page "test" and "dashboard/test" where both including the only following line: <span class="glyphicon glyphicon-trash"></span>

And again got the following errors:
chart:1235 GET net::ERR_ABORTED 404 (Not Found)
chart:1265 GET net::ERR_ABORTED 404 (Not Found)
chart:1 GET 404 (Not Found)

Why am I getting these errors?

Well, both front and dashboard pages includes <link rel="stylesheet" type="text/css" href="/concrete/themes/elemental/css/bootstrap-modified.css"> and the front pages also includes <link href="/concrete/css/app.css?ccm_nocache=ca17add95b11d1baf3d74fcd3fa4637fb02c14ba" rel="stylesheet" type="text/css" media="all">. And both these files include the following line:

@font-face {
  font-family:"Glyphicons Halflings";src:url("../fonts/glyphicons-halflings-regular.eot");src:url("../fonts/glyphicons-halflings-regular.eot?#iefix") format("embedded-opentype"),url("../fonts/glyphicons-halflings-regular.woff2") format("woff2"),url("../fonts/glyphicons-halflings-regular.woff") format("woff"),url("../fonts/glyphicons-halflings-regular.ttf") format("truetype"),url("../fonts/glyphicons-halflings-regular.svg#glyphicons_halflingsregular") format("svg");

So, when /concrete/css/app.css is accessed, the css file looks in /concrete/css/../fonts/* which resolves to /concrete/fonts/* which doesn't exist.

Am I the only one experiencing this?

EDIT - As an interim hack, I copied /concrete/css/fonts to /concrete/fonts, and then also copied all the files in into that directory. Surely, this is not what I should be doing...
JohntheFish replied on at Permalink Reply
If you have found a bug with latest core, please boil it down to the basics of the bug and report it as an issue on github.

I wouldn't be surprised, the core and most developers use font-awesome, so any code relating to glyphicons won't have been well exercised.
NotionCommotion replied on at Permalink Reply

Off topic. Unless I have a reason to use glyphicons-halflings, I probably should use fontawesome just because it is more common, used, and tested, true?
JohntheFish replied on at Permalink Reply
True. Also Font Awesome involves a lower page weight because its loaded anyway by many blocks and the dashboard.
NotionCommotion replied on at Permalink Reply
Thanks John, After all that and now I change to font-awesome :)