Jump to content

Robin S

Members
  • Content Count

    3,872
  • Joined

  • Last visited

  • Days Won

    229

Everything posted by Robin S

  1. Yes, this is easiest to do if you apply the sorting as the page is saved. So you won't see the sorting immediately after the images are uploaded, but will see the sorting after the page is saved and Page Edit reloads. In the examples below you would add the hook code to /site/ready.php The sort settings for child pages prevents the editor from making any other sort order apart from the one specified. So if you want something like that for images, where the newest images are sorted first, it's very simple: $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); $pages = $event->object; if($page->template == 'your_template') { if($page->isChanged('your_images_field')) { // Sort the images from newest to oldest $page->your_images_field->sort('-created'); } } }); But if you want to sort newly uploaded images first once the page is saved, but still let your editors customise the sort order after that, then you can use this hook: $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); $pages = $event->object; if($page->template == 'your_template') { if($page->isChanged('your_images_field')) { // Get the old version of the page, without the current changes $old_page = $pages->getById($page->id, [ 'cache' => false, 'getFromCache' => false, 'getOne' => true, ]); // Get the names of the existing images on the old page $existing_image_names = $old_page->getFormatted('your_images_field')->implode('|', 'basename'); // Get the newly added images $new_images = $page->your_images_field->find("basename!=$existing_image_names"); // Prepend the new images to the start of the Pageimages WireArray foreach($new_images as $new_image) { $page->your_images_field->prepend($new_image); } } } });
  2. You can use the API for this - covered in this post:
  3. I don't think it's possible to use regex in config.allowedContent, but this seems to do the job: CKEDITOR.on('instanceReady', function(event) { var rules = { elements: { a: function(element) { // If a link href starts with 'javascript:'... if(element.attributes.href.substring(0, 11).toLowerCase() === 'javascript:') { // ...then the href is invalid so remove the link delete element.name; } } } }; event.editor.dataProcessor.htmlFilter.addRules(rules); event.editor.dataProcessor.dataFilter.addRules(rules); });
  4. Here's a hook (add to /site/ready.php) that allows you to set a description and your own help notes for each checkbox in the Status field: // Add some extra notes to the options in the Status field of Page Edit $wire->addHookAfter('ProcessPageEdit::buildFormSettings', function(HookEvent $event) { /** @var InputfieldWrapper $form */ $form = $event->return; $status = $form->getChildByName('status'); if(!$status) return; // Add a description to the field if you like $status->description = 'You can apply various statuses to this page to control its visibility and editability.'; $options = $status->options; // Define your notes here $notes = [ 2048 => 'Peter Piper picked a peck of pickled peppers.', // Unpublished 1024 => 'How much wood would a woodchuck chuck, if a woodchuck could chuck wood?', // Hidden 4 => 'She sells sea shells by the seashore.', // Locked ]; foreach($options as $key => $value) { if(!isset($notes[$key])) continue; $options[$key] .= "[br]{$notes[$key]}[br] "; } $status->options = $options; });
  5. There's a module for that: https://modules.processwire.com/modules/template-tags-edit-list/
  6. I take this to mean you want the names of the user's roles, excluding the guest role, as a pipe separated string that you can use within a selector string. One-liner: $user_roles_string = $user->roles->find('name!=guest')->implode('|', 'name'); Other ways: $user_roles = []; foreach($user->roles as $role) { if($role->name === 'guest') continue; $user_roles[] = $role->name; } $user_roles_string = implode('|', $user_roles); $user_roles_string = ''; foreach($user->roles as $role) { if($role->name === 'guest') continue; $user_roles_string .= "$role->name|"; } $user_roles_string = rtrim($user_roles_string, '|');
  7. @Roope, thanks for the update. However, the update wasn't encoding email addresses for me. After some debugging I think the problem is that this... "((?:<(?:head|script|textarea|option|output)).*(?:<\/(?:head|script|textarea|option|output)>))" ...and this... if(!in_array(substr($str, 0, 5), array('<head', '<scri', '<text', '<opti', '<outp', '<inpu', 'value', 'label', 'data-'))) { ...result in the HTML getting split on the <header> tag and then email addresses following that tag are not encoded.
  8. @tpr, could you please make the styles that AOS applies to Select2 more targeted so that it's possible to use Select2 separately in the PW admin without being affected by AOS styles? At the moment there are AOS styles like this... .select2-selection.select2-selection--single, .select2.select2-container, span.select2-dropdown { width: auto !important; min-width: 300px !important; max-width: 640px; } ...which will apply to every Select2 instance and are impossible to override to get back the inline style that Select2 uses to set the dropdown width dynamically. It would be better if these could be something like: .aos-select2.select2-selection.select2-selection--single, .aos-select2.select2.select2-container, span.select2-dropdown { width: auto !important; min-width: 300px !important; max-width: 640px; } See "dropdownCssClass" and "selectionCssClass" in the Select2 options. Thanks!
  9. "exe" is among the file extensions that is blocked in WireUpload.php /** * Disallowed extensions for uploaded filenames * * @var array * */ protected $badExtensions = array('php', 'php3', 'phtml', 'exe', 'cfm', 'shtml', 'asp', 'pl', 'cgi', 'sh'); But it turns out you can override this by setting your own custom array of blocked extensions in your /site/config.php // Remove "exe" from array of file extensions blocked by WireUpload $config->uploadBadExtensions = array('php', 'php3', 'phtml', 'cfm', 'shtml', 'asp', 'pl', 'cgi', 'sh'); Of course exe is probably blocked by default for a reason so you would want to do your own research about possible risks involved in allowing such files on your server.
  10. v0.3.2 released. This version reverts to the hook methods used in v0.2.3 and earlier of this module now that the core circular reference issue was fixed in PW v3.0.166. To upgrade to v0.3.2 you must be running PW v3.0.166 or newer, which is currently only available on the dev branch.
  11. Yeah, we all struggle with that sometimes. 🙂 I did a bit of experimenting and here's another way the language options can be removed from the title field: // Single-language title field for "test-template" at Page Add $wire->addHookAfter('ProcessPageAdd::getAllowedTemplates', function(HookEvent $event) { $tpls = $event->return; $t = $event->wire()->templates->get('test-template'); if(isset($tpls[$t->id])) $tpls[$t->id]->noLang = 1; $event->return = $tpls; }); // Single-language title field for "test-template" at Page Edit $wire->addHookAfter('ProcessPageEdit::buildFormContent', function(HookEvent $event) { /** @var InputfieldForm $form */ $form = $event->return; $page = $event->object->getPage(); if($page->template == 'test-template') { $title = $form->getChildByName('title'); if($title) $title->useLanguages = false; } });
  12. I might be misunderstanding something (I don't normally work on multi-language sites), but isn't it optional to enter page titles in any language other than the default? The user isn't forced to add a title in all enabled languages as far as I can see. So it seems like it's a question of user education more than anything else, the lesson being "only create page titles in languages that you need", which is really part of a more basic general lesson that any CMS user must learn: "only fill out fields that you have information for".
  13. Thanks for the prompt response, that fixes it here.
  14. Hi @adrian, In the Mail Interceptor panel, special characters are scrambled in the From field: I think this might be glitch in the Mail Interceptor panel rather than a WireMail issue because the From value seems to render properly in my email client. But if it isn't a Tracy issue and is actually a WireMail problem I'd want to report it to Ryan. Could you take a look when you have a chance? Thanks.
  15. @Macrura has created a couple of modules for adding help documents to the admin: Myself, I just create a PW page (hidden from non-superusers in the admin) that contains instructions for users. I use some custom jQuery in the admin to append an "Instructions" view link to the admin footer so the document is always easily accessible from any page. To provide some intervention against duplicate pages you could try a hook like this: $pages->addHookAfter('added', function(HookEvent $event) { $page = $event->arguments(0); $pages = $event->object; // For pages with a particular template... if($page->template == 'basic_page') { // Check for existing page with the same title // You could get fancy by making this more fuzzy // E.g. exclude short words and then look for titles that contain the remaining words $existing_page = $pages->get("template=basic_page, title={$page->title}"); if($existing_page->id) { // You could use the edit URL or view URL as appropriate $url = $existing_page->editURL; $event->wire()->warning("There is an existing page with this title <a href='$url' target='_blank'>here</a>. If you have added a duplicate page by mistake please delete this page.", Notice::allowMarkup); } } });
  16. I don't understand what you're saying here or what screenshot you're referring to. But my general point is that fields like Page Reference or Repeater are ultimately about storing a relationship between pages (Repeater items are pages). Rather than use a field to store the relationship, you can use the parent-child relationship. In PW, until pagination support is eventually rolled out to Page-type fields only the parent-child relationship can scale to thousands or millions of pages. But for your case this should be no big problem because the parent-child relationship can achieve what you are doing with the Repeater field. You get a nice sortable paginated list of child pages on the Children tab, and you can customise the page labels in a similar way to the Repeater item labels (see "List of fields to display in the admin Page List" in the Advanced tab of the child template). I would just stick with the Children tab, but if you wanted try more things you could look at Batch Child Editor, or listing child pages using a runtime-only inputfield with modules like this or this, or making use of Lister / Lister Pro to view and filter the child pages.
  17. Personally, I don't allow non-superusers to see the trash and I like that they have to navigate to the Delete tab because I want them to think very carefully before they delete a page. If you want to hide Trash (as per the setting mentioned above) but want to let non-superusers trash pages from Page List then you could look at this module:
  18. FYI, you can disable trash for non-superusers in the ProcessPageList module settings: https://processwire.com/blog/posts/processwire-3.0.107-core-updates/#trash-for-all
  19. I'm not surprised that 1000 repeater items in a field is slow to load. My suggestion is to replace your repeater field with child pages.
  20. I don't know the exact reason why your "TEST<br>" line is output twice, but what you're doing there is not correct usage of Markup Regions. The docs explain that when using Markup Regions you set... $config->appendTemplateFile = '_main.php'; ...so that every template file will append the markup contained in _main.php. And... This means that all the markup that is in a template file will be output before the <html> tag that is in _main.php. Of course that would normally be invalid HTML because no markup should occur before the opening <html> tag. But as the docs explain... So all the markup in a template file should correspond to a matching region that is defined in _main.php, so that when Markup Regions parses the output it can relocate the markup in the template file into the corresponding regions defined in _main.php. If you have markup in a template file that does not correspond to a region in _main.php then Markup Regions is not going to be able to make sense of it, and that is what's happening with your "TEST<br>" line. To confirm you can enable debugging for Markup Regions and it will alert you to problems: https://processwire.com/docs/front-end/output/markup-regions/#debugging-regions
  21. Yes, it's still the same as it was, it's just that in the documentation the getById() method has been replaced with getByIDs() since v3.0.156. See "joinFields" here: https://processwire.com/api/ref/pages/get-by-i-ds/ Example with $pages->find(): $items = $pages->find("template=colour", ['loadOptions' => ['joinFields' => ['headline', 'text_1']]]);
  22. I can confirm the problem. GitHub issue opened here: https://github.com/processwire/processwire-issues/issues/1253
  23. https://processwire.com/docs/fields/select-options-fieldtype/#manipulating-options-on-a-page-from-the-api
×
×
  • Create New...