LMD

Members
  • Content count

    29
  • Joined

  • Last visited

Community Reputation

24 Excellent

About LMD

  • Rank
    Jr. Member

Profile Information

  • Gender
    Not Telling
  1. Adding a 'class' attribute to an element is different to adding other attributes, you add either allowed class names or a '*' wildcard within parenthesis. // Allow *any* class name img(*) // Allow only specific class names img(align_left,align_right) // In your case (assuming any class name) it would be: a(*) Here's the CK Editor docs for Allowed Content rules: https://docs.ckeditor.com/#!/guide/dev_advanced_content_filter https://docs.ckeditor.com/#!/guide/dev_allowed_content_rules
  2. Thanks, @kongondo - the fix works perfectly.
  3. Hi @kongondo - I'm still getting an issue with HTML in the menu item titles, where quoted attributes (e.g., class names, such as those used FontAwesome icons etc) get garbled in the title's input field. I did mention a very simple fix earlier in this topic, but it may have got overlooked. Would it be possible to apply this fix to the module: In the ProcessMenuBuilder.module file, on line #1158 (in the listMenu() menthod), surround the $title variable with the htmlentities() function: // Change line #1158 from: <input type="text" value="' . $title . '" name="item_title[' . $id . ']" class="menu_settings" id="item_title' . $id . '"> // To: <input type="text" value="' . htmlentities($title) . '" name="item_title[' . $id . ']" class="menu_settings" id="item_title' . $id . '"> It immediately fixes the HTML display issues witin the input field. Thanks.
  4. And I've now tested it too, and it works perfectly. Thank you @Robin S
  5. @Robin S Jonathan's concern regarding the stability of 'IDs' vs. 'text' was one of my concerns. After thinking about it, I was going to suggest if a hookable method was possible, so this makes me happy. I'll try it out today and report back!
  6. After using this module for a while, I have a couple of suggestions for future modifications. First, would it be possible to skip the dialogue window (or auto-close it) if the Hanna code being added does not have any attributes set? It could still have the on-click behaviour after being added (with the "This tag has no editable attributes" message), to future-proof the tag should the user add attributes in the future. Obviously, one could just type the Hanna code, but it is more convenient for clients to pick it from a list. Secondly, this isn't really a suggestion, but a custom modification I made to the code for my own purposes, which might be useful to others. When using selectable option fields (selects, radios, etc), the current method to set the different options is simply: attribute__options=Option A|Option B|Option C // The option string format is the same for dyanamically generated options. With this method, the option field input 'value' and 'text/label' are the same. However, I found that this was not very user-friendly when the options are somewhat cryptic. Eg, from a returned file list: file123-xyz.pdf abc-1978.pdf xyz-blah123.pdf really-long-title-2017-05-apple-blueberry-banana.pdf So, what I did was modify the foreach loop code in the file 'iframe_form.php' at line #63, to make it possible to have a separate input value and text. /* Original code at line #63 in iframe_form.php */ foreach ($select_options as $select_option) { $f->addOption($select_option); } /* My own modification * - Searches the option value for '@@' * - Uses it to split the string into two variables: $optionValue and $optionText * - Then adds the option to the select field. */ foreach ($select_options as $select_option) { if (strpos($select_option, "@@") !== false) { list($optionValue, $optionText) = explode("@@", $select_option); $f->addOption($optionValue, $optionText); } else { $f->addOption($select_option); } } Now, when setting the options, you specify them (either directly or dynamically) by separating each option's value and text/label with '@@' (chosen because it's unlikely to be part of an option value or text): attribute__options=file123-xyz.pdf@@Annual Accounts 2016|abc-1978.pdf@@Some Meaningiful Title|xyz-blah123.pdf@@Another Meaningful Title| really-long-title-2017-05-apple-blueberry-banana.pdf@@The Price of Fruit May 2017 // Note: in reality the above options would be generated dynamically. I would make a pull request (?) via GitHub for this, but I've never used it for such a thing and don't really know how.
  7. @Robin S Yes, it's fixed, thank you!
  8. I've been doing something very similar -- might I suggest a small change to the page selector to eliminate the need to check for the current page in your foreach loop? // Find the pages that use the specified tag -- and ensure the current page is excluded $articles = $pages->find("template=basic-page, id!={$page->id}, tags.title=$tag, limit=8"); This way, you always get 8 results (if there are that many, of course), whereas excluding page from the loop would leave you with 7 pages.
  9. This module is just what I was looking for! I'm using it to create links to a file download page, instead of to the file itself, with the 'dynamic options' method. However, although it works perfectly, I'm getting a strange error in the Hanna dialogue modal window (see screenshot): I have tried deleting the file compiler cache, but it did not resolve the issue. Set-up Info: Hanna Code: ver. 0.2.0 HannaCode Dialogue: ver. 0.0.3 ProcessWire: ver. 3.0.58 PHP: ver. 5.6.21
  10. @kongondo Thanks, I got the menu working with a custom menu builder functions. I couldn't help myself from digging around the in the the module code, though . I think I've found what seems to be a fairly simple solution to the quoted attributes breaking the form output. In ProcessMenuBuilder.module, on line num. 1111: https://github.com/kongondo/MenuBuilder/blob/bfc032cb3a07b65e732469b16b5286563bd709e9/ProcessMenuBuilder.module#L1111 Change: <input type="text" value="' . $title . '" name="item_title[' . $id . ']" class="menu_settings" id="item_title' . $id . '"> To: <input type="text" value="' . htmlentities($title) . '" name="item_title[' . $id . ']" class="menu_settings" id="item_title' . $id . '"> The htmlentities() function deals with the issue of quotes breaking the form input. I've tested it on my site and it seems to be working just fine. The icons display in the front-end and the admin widget item label, and the code displays in the item's title edit field after being saved. I don't know if I've missed anything though?
  11. Hello, me again. I've encountered another issue with Menu Builder. This time it's related to HTML in the titles. I wanted to add FontAwesome icons to a menu, so enabled "Allow HTML in menu items title" in the settings for the menu. I then added the FontAwesome code to the title field, like this: When I saved the menu, it went weird and broke the editor widget (n.b. it's the same outcome using either single or double-quoted attributes): Like the previous issue, the title does save to the DB (and when I looked at a frontend page, it showed the icon as it should), but when I tried to save the page again, the broken menu item completely disappeared (is not saved to the DB at all) and I had to add it again. I think the menu editor widget doesn't like the HTML attributes, because it works fine with plain HTML elements without attributes. Current Workaround: Add a CSS class to the list item wrapper and manually add the FontAwesome icon in the site stylesheet. Using: Processwire: ver 3.0.50 MenuBuilder: ver 0.1.7
  12. Gosh that was quick. Works a charm. Thanks!
  13. Hi, Great module - it's just what I needed! However, I'm encountering a weird issue with some menu item titles. If a menu item title contains an apostrophe/single-quote, the characters following (and including) the apostrophe are removed after saving the menu. For example, the title "What's On" becomes "What". It's ok if it is the initial save after adding that menu item, the apostrophed title is saved to the db, but it is subsequent saves that remove it. It appears the characters are stripped when the title is displayed in Menu Builder's menu item editor widget. Currently, the work around is to just retype each menu item that gets stripped before saving each time. Using: Menu Builder: ver. 0.1.6 Processwire: ver. 3.0.47
  14. @szabesz Good idea. I don't actually have a GitHub account, but I really ought to and now seems as good a time as any.
  15. [Edit: this issue was fixed in PW 3.0.40] I've recently noticed a small bug, but my Google-fu didn't find any mention of it anywhere else: When using the long-click modal window to edit a page from the Admin page tree, if there is a field submission error (e.g., a required field is missing/incorrectly formatted etc), the "Save" button completely disappears, preventing the page from being saved at all. I think it is a javascript issue because it only happens when fields are validated with the HTML5 required attribute (in the field settings the "also use HTML5 'required' attribute" option is checked). HTML5 validation halts browser submission, but I suspect the javascript is still submitting the form (but sadly, not saving it!), hence the button vanishing. It's not really a big issue, you can just not use the long-click edit modal (or not use HTML5 validation, but I like the convenience of it), but I thought it ought to be mentioned. Not really sure what the solution is either. I've observed this in: PW version 3.0.39 dev (was using ver. 3.0.34 where I first noticed the problem, I updated specifically to see if it already been fixed). Browsers tested: Firefox and Chrome - both have the same issue.