LMD

Well, although I am using Image Extra in my example, I'm talking about the core image description field, which has no label. I'd like to be able to add a label to it regardless of whether I'm using the Image Extra module.

I'm wondering if it is possible to add a label to the description input in image fields (in the admin). I'm using the module Image Extra, which has labels for each input, but I'd like to add a label to the default 'description' input too. The image below illustrates this: If there is no way (no hook?) then, I suppose I could just not use the default description and add a new description input with the Image Extra module. But I thought I'd ask in case I (or others) ever want to do this without using the module (i.e. just the one input required). I'm using PW 3.0.98 Thanks. --- FYI: yes, that is a cat and not a quilt -- this is on my local dev server and I don't have the actual photos yet! She is on a quilt, so it counts... technically.

I am doing something very similar to this and am just using pages. I use two templates: 'newsletters_parent' and 'newsletters_child'. The 'newsletters_parent' is the container and onyl has a title, but its settings on the "Family" tab are: Can have children: YES Can be used for new pages: ONE Allowed template(s) for children: newsletter_child Name format for children: Y/m/d H:i:s (the page creation date/time -- this will get overwritten at a later stage) Sort settings for children: pub_date (a field that will be added to the newsletter_child page) Reverse sort direction: CHECKED (yes) The 'newsletters_child' template has the following fields: title (default and required by all templates) pub_date (a datepicker field set to YYYY-MM-DD -- the publication date might not necessarily be the same as the date the file was uploaded!) pdf_file (file-upload field, single file only, and also set to only allow PDF files) The settings ("Family" tab) for the child template are: Can have children: NO Can be used for new pages: YES Allowed template(s) for parents: newsletter_parent Show in the add-page shortcut menu: YES To make the process of adding a new newsletter as easy as possible for users -- all they have to do is select the file to upload and the pick the pub date -- I use a couple of hooks hook in the site's ready.php file: The first hook adds dummy text to the page title field on page creation so that the user doesn't have to enter anything (if it is left blank, it will throw an error) -- the proper title, along with the page name will be created from the pub_date field when the page is saved. The second hook also creates the actual page title and the sets page name based on the supplied 'pub_date'. [NOTE: the newsletters only get published once a month, so we only use the Year/Month in page names/titles.] /** * 1. Set a dummy title on page save at creation, to prevent the required field showing an error if it is blank. * (Requires the parent template option 'Name format for children' to be set) * 2. Modify newsletter title and page name from pub_date before saving. */ $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); // Only on newsletter_child templates where the title is blank (on page creation) if ($page->template->name == 'newsletter_child' && $page->title == '') { $page->title = 'Newsletter'; // a dummy title, will be replaced at a later stage } // Only on newsletter_child templates with a pub_date if ($page->template->name == 'newsletter_child' && $page->pub_date) { $newName = wire('sanitizer')->pageName('newsletter-' . date('Y-M', $page->pub_date), true); $newTitle = date('F Y', $page->pub_date); if ($page->title != $newTitle) { $page->title = $newTitle; } if ($page->name != $newName) { $page->name = $newName; } } }); Thiis then makes it easy to search the system for whatever you want: // All newsletter files (no limit applied) $allNews = $pages->find('template=newsletter_child, sort=pub_date'); // ascending order (earliest first) $allNews = $pages->find('template=newsletter_child, sort=-pub_date'); // descending order (most recent first) // All newsletters from a particular year (e.g., 2017): $yearStart = strtotime('2017-01-01 00:00:00'); $yearEnd = strtotime('2018-01-01 00:00:00'); $yearNews = $pages->find("template=newsletter_child, pub_date>={$yearStart}, pub_date<{$yearEnd}, sort=-pub_date"); // The most recent newsletter: $mostRecent = $pages->findOne('template=newsletter_child, sort=-pub_date'); // Accessing the file itself (using $mostRecent) if ($mostRecent->pdf_file) { $file = $mostRecent->pdf_file; $downloadLink = "<a href='{$file->url}'>Download the newsletter: {$mostRecent->title}</a> ({$file->filesizeStr})"; } That's all there is, really. There is lots you can do with the system.

I've been using this field and appreciated the string of page IDs for PW pages. I'm wondering if instead of converting the ID to a URL before returning it, how about returning an object? So, Instead of $page->AssistedURL returning just a string "/mypage/" (internal) or "http://www.anothersite.com/" (external), it returns the object: // Internal PW page { 'id' => 1234, 'name' => 'mypage', 'url' => '/mypage/', 'httpUrl' => 'http://my-processwire-root.com/mypage/' } // External link { 'id' => 0, // 0 or null 'name' => '', // blank or null 'url' => 'http://www.anothersite.com/', 'httpUrl' => 'http://www.anothersite.com/' // url and httpUrl are the same for external links } // Accessing the data $page->AssistedURL->id $page->AssistedURL->name $page->AssistedURL->url $page->AssistedURL->httpUrl For backwards compatibility, could $page->AssistedURL by itself be a magic method to return the URL as it currently does? By returning relative and absolute links, the same field could be used in multiple situations (eg, on an internal menu, and in an email template).

Couldn't you just use radio selects, with two options (with whatever labels you need), make it required and have one of the radios selected by default?

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

Thanks, @kongondo - the fix works perfectly.

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.

And I've now tested it too, and it works perfectly. Thank you @Robin S

@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!

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.

@Robin S Yes, it's fixed, thank you!

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.

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

@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?

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

Gosh that was quick. Works a charm. Thanks!

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

@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.

[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.

Um, well, I am now feeling very sheepish... I've found the problem and it is monumentally stupid of me. I was trying to include the template partial _BEFORE_ I had run the function to do the search, so of course the variable was empty! The other places I was using the variable were after the function had run! I only spotted it after spending some time away from the code. I've now rejigged the code so it works as intended. Sorry for wasting anybody's time.

I have a strange problem and I don't know if it's bug or I'm just not quite understanding something right. I'm using ProcessWire 3.0.34. I have a search box fragment (the HTML) in a separate template which I 'include' via wireRenderFile() because I'm using the delayed output method for my templates. It works perfectly well, and shows the form. However, on the search results page, I also want to show the keywords that were entered in the search text input. This should be easy, my search function sanitises the user input (the search form uses GET) as a selectorValue and saves it to the $input->whitelist. This is where it gets weird. On the search results page itself I can spit out the whitelisted variable ok for the "you searched for 'blah'" text, but it doesn't get passed to the file included by wireRenderFile to show in the search form text input. I thought all PW API variables (in this case $input) were available to included files and that only custom variables had to be passed as an array? My first thought was that there is a context issue, so I tried wire('input') instead, but that didn't work either (and it didn't show an error), so my second thought was that maybe $input is not passed automatically and only the $page object is ($page->whatever does work), so I tried to pass the value I wanted as a custom variable: $page_body .= wireRenderFile("includes/comic-search-form", array( 'search_keywords' => $input->whitelist->search_keywords )); // Note the variable works perfectly elsewhere on the template calling wireRenderFile: $page_body .= "You searched for: {$input->whitelist->search_keywords}"; // WORKS! In the included file, I then used: <input type="search" name="search_keywords" id="search_keywords" size="30" placeholder="Enter keywords" value="<?php echo $search_keywords; ?>"> <!-- note, when working, the code will check the $search_keywords actually has content before echoing --> However, it still came out blank! So I did some more tests passing other variables and also used Tracy Debugger to var dump: bd($input->whitelist->search_keywords, 'Before'); $page_body .= wireRenderFile("includes/comic-search-form", array( 'test_a' => $page_summary, // another custom variable from the template 'test_b' => 'This is a test', // a direct string 'search_keywords' => $input->whitelist->search_keywords )); // On the incude file itself, I did the following bd(array($test_a, $test_b, $search_keywords), 'Inside wireRenderFile()'); echo "<pre> Test A (variable): $test_a Test B (string): $test_b Search Keywords: $search_keywords </pre>"; In the Tracy output and the directly printed output the $test_a and $test_b variables worked perfectly as expected, but the $search_keywords was always blank (null)! Weirdly, in the output on the template calling the wireRenderFile ("Before"), the Tracy output for $input->whitelist->search_keywords was also blank!? If I can echo out the $input->whitelist->search_keywords value on the template it is called on, why can I not then save it as a variable to be passed to wireRenderFile ? Is there something I am overlooking or not understanding?

I'm not sure automatically clearing when a template file is changed is worth the overhead (unless PW already does the steps necessary to achieve it). The system would have to check the modified time of every template file to decide if it is newer than the cached version _every time_ a page is loaded/rendered. Yet template updates shouldn't be that frequent once a site is up and running (so it would mostly be a wasted overhead), and when they do happen it would still be easier on the system to just disable the cache completely while those updates are being made. And what about changes to files that are included into a template, which the PW system won't necessarily 'know' about in order to compare modified dates?

@Robin S It has nothing to do with the default behaviour of the template cache -- it is clearing the cache when it should do. At least I've not noticed any issues when logged-in, saving pages or using GET/POST whitelist. Adding/removing/changing fields - I don't know, but adding fields is at least usually accompanied by modifying pages (to add the new data), which would clear the cache. However, making changes to the template files does not clear the cache. Which is one of my issues. My other issue is laziness If I'm logged-in (which would prevent caching), I'm not getting the normal visitor ('guest') experience/view. I just wanted one simple place to disable the cache temporarly for multiple templates, without having to log-in, add a no-cache GET variable (and then have to add it to every URL in dev) or disable it on every template that uses it. it would also be useful on staging sites, where you may enable caching to show clients how fast it can be (and for testing), but might want to disable it when making changes. Or even on the live site itself -- globally disable the cache (and then dump it via the module's settings page), make the updates/upgrades while the cache is disabled (preventing visitors from triggering caching), then once the updates are made/tested, enable the cache again. This is where Soma's solution works a charm - it creates that simple/quick config setting and and only involves a few lines of code in the ready.php file.

Thank you Soma. Yeah, I know about being logged-in and GET/POST vars, but that wouldn't apply here (need to view the site when logged out too). However the code you suggested is perfect and does the job. I modified it slightly so it will work in the ready.php context: // Code for ready.php context instead of module context $this->addHookBefore('Page::render', null, 'doNotCache'); function doNotCache($event) { if(wire('config')->disableTemplateCache) { $args = $event->arguments(1); $args['allowCache'] = false; $event->setArgument(1, $args); } } This could easily be expanded to look for sessions/cookies too that aren't related to being logged-in but might necessitate disabling the cache while they are present (either globally or on particular templates/pages).