Robin S

If I was the vendor of a product that currently has 77% market penetration I think I would keep going on. It is the most popular JavaScript library by a staggering margin: With so many happy customers it's fantastic news that jQuery continues to be updated and supported, and I don't see how its use in the PW core disadvantages users in any way.

Yeah, I've noticed that too and I think it's a bug. I normally select the "except when superuser" option and it does work then but this shouldn't be necessary. I opened an issue here: https://github.com/processwire/processwire-issues/issues/1879

I could probably add an option to support this but I can see it introducing worse issues than it solves. It would make it impossible to save any attribute value where that value has been deliberately set at a value that also happens to be the default. What if the user wants to create a tag where the values should be [[mortgage_calculator default_amount="70000" default_rate="4" default_type="repayment" default_term="25"]]? If all of those attributes get stripped out and you later change the defaults then the tag produces an unintended result. I think the scenario where you have attributes whose default value you intend to later change is a fairly rare one, and in that scenario you'd be better to not configure a default within the Hanna tag but rather use some other means (e.g. inputfield description or notes text in the dialog) to communicate to the user that there's a fallback value that's used when no value is specified and this fallback is subject to change. That way you can distinguish between when a user has chosen a value or not. But if you still want the feature and can live with the side-effects then let me know and I'll look at adding it.

If you like that approach you might like to try the Repeater Depth Helper module which is a development from that earlier idea. It gives you the depth structure for the whole repeater field from one method and also enforces a couple of depth rules to keep things sane.

Page Edit Per User takes the approach of first checking if PW says the user can edit a page, and if the answer is "yes" it returns early and doesn't apply any logic after that. So it only ever adds edit access and never removes it. For your scenario I think you'll need to approach it differently and give the role the necessary permissions to edit, create and add children for all pages having the templates in question. Then in your hook remove the edit/add permission for individual pages according to your test for when the user is not allowed to edit or add children. You do that in hooks to Page::editable and Page:addable by setting the event return to false. And in contrast to Page Edit Per User you'll only need to apply your hooks to users with a particular role. So your init method might look like this: public function init() { if($this->wire()->user->hasRole('limited')) { $this->addHookAfter('Page::editable', $this, 'hookPageEditable'); $this->addHookAfter('Page::addable', $this, 'hookPageAddable'); } }

Yes, exactly. Everything in the vulnerability description after "we require a user account with administrative privileges and the application must have debug mode activated" seems redundant to me. At that point it's game over. Rather than following all the subsequent steps you could simply install Tracy Debugger and start executing arbitrary PHP code in the Console panel. It's up to every superuser to ensure that malicious users cannot get an account with administrator privileges so I don't understand how this vulnerability description adds anything beyond that basic point.

Right, makes sense. You could change to a CKEditor field as this keeps full absolute URLs if you paste them in. But I actually think this is a good use case for a hook like you are already using, or a custom textformatter module. That way you can use all the normal features of the pwlink plugin and the string replacement is dead simple.

@Roadwolf, HTML Purifier doesn't include irc:// in its allowed URI schemes. PW does provide some ability to hook into the HTML Purifier configuration via MarkupHTMLPurifier::initConfig but in the case of adding a scheme this seems difficult to achieve. The MarkupHTMLPurifier::initConfig method is only called when there is no cached configuration for HTML Purifier and yet the cached config doesn't seem to include the relevant "URI.AllowedSchemes" setting. So you'd need to be continuously clearing the cached config. Plus you would also need to include a custom class to validate the irc:// scheme so it's available to HTML Purifier. All in all it would be a lot easier just to use a Hanna code for IRC links when you need them, e.g. [[irc_link uri="irc://irc.efnet.org/mIRC" text="My link text"]]. In the Hanna code you would use the uri and text attributes to output the link.

Using full absolute URLs for internal website links is liable to cause trouble down the line. For example, if the website domain changes you have to update every internal link. Instead you could add a <base> element to your _main.php.

Thanks. Maybe that would be been a viable alternative if I had investigated it at the start, although I think there would be a lot of challenges (for example, MarkupAdminDataTable doesn't provide the necessary hooks). But I've been using this module privately for some years now and I think it does the job just fine so I don't want to reinvent it all now.

I received a suggestion from @monollonom that it would make more sense if the module appeared under the Access menu rather than the Setup menu. I agree so I've changed to this in v0.1.5. If you've installed < v0.1.5 and you'd like to have the module under Access then there a couple of ways to do this. First update to v0.1.5 and then either... Uninstall the module, and then reinstall the module so the page will be automatically created under Access during install. Or move the "Template Access" page within the Admin branch from under Setup to be under Access.

Template Access A Process module that provides an editable overview of roles that can access each template. The module makes it quick and easy to see which templates have access control enabled (personally I like to ensure I've enabled it for every template) and to set the appropriate access per template. Usage The Template Access page under the Access menu shows access information for all non-system templates in a table. You can filter the table rows by template name if needed. Click an icon in the table to toggle its state. The changes are applied once you click the "Save" button. Sometimes icons cannot be toggled because of logical rules described below. When an icon cannot be toggled the cursor changes to "not-allowed" when the icon is hovered and if the icon is clicked an explanatory alert appears. A role must have edit access before it can be granted create access. If the guest role has view access for a template then all roles have view access for that template. https://github.com/Toutouwai/ProcessTemplateAccess https://processwire.com/modules/process-template-access/

Thanks for the report, should be fixed in v0.1.4.

Glad you like it! That would really be a different purpose than what this module is for. So that idea would be for a different module rather than a feature of this module. Although it wouldn't work exactly as you describe, as it happens I have another module that's 90% finished and just waiting for a core issue to be resolved. This module is designed to make it easy to copy or move images from one field to another, so it could be used together with Media Lister to copy an image, just with one or two more steps. I'll come back and explain more once the module is released. But as a general thing, are you sure you want to be duplicating image files across the site like this? If you have images that need to be regularly reused on different pages you could look at an "image reference" solution instead, so the image file stays in a single place and is referenced on other pages. My Select Images module provides for a basic solution, but if you need more power you could look at a "page per image" approach which is used in modules such as Media Manager and Visual Page Selector by @kongondo

No, this module is a fieldtype, and Combo is also a fieldtype. There isn't such a thing as one fieldtype module working inside another fieldtype module. But you can easily add both a Dynamic Options field and a Combo field to your template so that you can use them together. You can even have the Dynamic Options inputfield adjacent to any particular Combo subfield in Page Edit thanks to the "Custom form placement" option for Combo subfields:

I can't think of any reason or way that this module could be related to what Google crawls, so I think the timing must be a coincidence and the cause is something else.

Here is one: https://processwire.com/modules/inputfield-easy-mde/

As far as I know, this is all that's needed to initialise an inputfield in all circumstances regardless of if AJAX-loaded or inside new or existing repeater items: function initMyCustomType($el) { // Initialise whatever is needed for $el here... } $(document).ready(function() { $('.InputfieldMyCustomType').each(function() { initMyCustomType($(this)); }); }); $(document).on('reloaded', '.InputfieldMyCustomType', function() { initMyCustomType($(this)); });

Inputfield::renderReady() is the correct core method for ensuring that JS and CSS dependencies for the inputfield get loaded in all circumstances - see the phpDoc comments for the method. It needs to be this method so that dependencies are loaded when the inputfield is within an AJAX-loaded repeater, for example. So I don't want to risk introducing problems by changing this for what sounds like an unusual usage of the module. But you could use a hook to call InputfieldRuntimeOnly::renderReady() after the method that calls FieldtypeRuntimeOnly::renderMarkup(). $wire->addHookAfter('FieldtypeRuntimeOnly::wakeupValue', function(HookEvent $event) { /** @var Page $page */ $page = $event->arguments(0); /** @var Field $field */ $field = $event->arguments(1); $inputfield = $field->getInputfield($page); $inputfield->renderReady(); });

Thanks for debugging this. Although I can't reproduce it here I can see a solution - please update to v0.1.2 for the fix.

It's good to be aware that this can happen - I've made an update in v0.1.1 to fall back to the plain text if the description value cannot be decoded as JSON. But I don't think this can be the reason for "array-0" because json_decode() returns null if the supplied value cannot be decoded as JSON. Of the database values you showed in the screenshot, which is the one that is displayed as "array-0" in Media Lister? Or are all descriptions displaying that way? It's hard for me to debug this because I can't reproduce the issue here on a two-language site. The code that formats the description from the raw database value is here: https://github.com/Toutouwai/ProcessMediaLister/blob/f744014bb402d2de25888c89e3db4bcced80ff32/ProcessMediaLister.module#L426-L452 If you use Tracy Debugger to dump variables within this section you might find where the "array-0" is creeping in. Or maybe somebody else will have the same issue and we can find out more then.

That looks like it might be the result of an array to string conversion error, but the module should handle multi-language descriptions that decode from JSON to an array. Maybe the database has something unexpected in the description column. I don't work with multi-language sites so I'm not very familiar with them, but when I tested by entering descriptions on a site with two languages the description column looks like this: The first row has a description in the non-default language but not the default language, the second row has descriptions in both languages, the third row has a description in the default language but not the non-default language, and the fourth row has no description in either language. The module handles all of these. Can you locate the description in PhpMyAdmin or Adminer (included with Tracy Debugger) and let me know what the raw database value is? If your images field is named "images" it will be in the "field_images" table.

GitHub has recently changed something that now makes it much more difficult to host readme images at GitHub without making them a part of the repo. There has long been a gotcha for previously private repos where if you if you added images before making the repo public then those image URLs wouldn't get the public subdomain. But now it seems that if a public repo has ever been private then GitHub forces the "private-user-images" subdomain, even retrospectively changing image URLs that previously had the public "user-images" sudomain. I can observe this in some of my recent modules where the PW forum post has the public URLs that were copy/pasted from the readme at the time the post was created but the readme at GitHub now has the "private-user-images" subdomain, which is going to make it a real drag to update the forum post when the readme is updated. And GitHub tricks you into thinking the image URLs are publicly accessible (I double-checked in an incognito window to make sure after the previous attempt to fix), but as this post describes the private URLs contain an encoded token that causes the images to expire after 5 minutes, although I don't know how any mere mortal is expected to know that. Presumably GitHub checks the referrer so the expiry doesn't occur when viewing the readme on GitHub itself. So the only solution I can see is manually changing all image URLs from the private to the public subdomain before using them in the readme - you can no longer conveniently use the GitHub image markdown directly from the "issue". I wrote a little Tracy Console script to make the process a bit less painful - might be useful to anyone else who changes repos from private to public and likes to host readme images at GitHub. // Require Simple HTML Dom: https://sourceforge.net/projects/simplehtmldom/ require_once $config->paths->templates . 'TracyDebugger/snippets/simple_html_dom.php'; // Get HTML from issue where images are embedded $html = file_get_html('https://github.com/Toutouwai/ProcessMediaLister/issues/1'); // Process images foreach($html->find('.markdown-body img') as $img) { $alt = $img->alt; $src = $img->src; // Remove query string $pos = strpos($src, '?'); $src = substr($src, 0, $pos); // Replace private subdomain with public subdomain $src = str_replace('private-user-images', 'user-images', $src); // Echo image Markdown for copy/paste into readme echo "<br>"; }

Thanks, hopefully fixed now.

Media Lister Lists images and files from across the site in a sortable and filterable table. For images you can choose between table, small thumbnails and large thumbnails view modes. The module retrieves the data using SQL queries so is able to efficiently list media information for all but the largest of sites. Possible use cases: Check that a nice variety of banner images is used for top-level pages. Find duplicate files/images by sorting by filesize or filename. Find images without descriptions if this is important for use in alt tags. Find large PDF files that would benefit from optimisation. Check for "inappropriate" images, or images that are not "on-brand". Images in small thumbnails view mode Files saved as a bookmark Controls Media type: Choose between Images and Files. View mode: When listing images you can choose between small thumbnails, large thumbnails and table view modes. When in one of the thumbnail view modes you can see information about the image in a tooltip by clicking the "i" icon, or edit the page containing the image by clicking the pencil icon. From pages matching: This field allows you to add filters to limit the pages that the media will be listed for. Add bookmark: Superusers can add bookmarks for the current settings that will be available from the flyout menu for all users. See the bookmarks section below for more information. Column visibility: Choose the columns that appear in the table and in the information tooltip (when in thumbnails mode). Search: Quickly filters the results to show only items that have the search text in any column, whether the column is visible or not. Custom search builder: For more advanced searches where you can combine conditions for specific columns with AND/OR logic. Pagination: You can navigate through the results and set the number of results per page. Reset: Click the "Reset" button at the top right to return to the default settings for Media Lister (or for the current bookmark if applicable). Editing the page that contains the media For any media result click the link in the "Page" column to open the page that contains the media item in Page Edit. When in thumbnail view mode you can click the pencil icon to achieve the same thing. The field that contains the media item will be focused. When a media item is contained within a Repeater field this is indicated by an asterisk at the start of the page title. When opening Page Edit for a media item within a Repeater field the Repeater item will be automatically expanded, including for nested Repeaters. Limitations for values that are merged in the database The module has limited support for multi-language values and custom fields for images/files. In order to be efficient enough to handle large sets of results the module retrieves raw values from the database, and in the case of multi-language values and custom field values ProcessWire stores these in JSON format in a single database column. The module improves the display of this JSON data by extracting the uploadName value into a separate column, substituting custom field labels for field IDs, adding language names where possible, and by transforming the data into a quasi-YAML format for better readability. Some limitation remain though – for example, if you use Page Reference fields in the custom fields then only the page IDs are displayed. Bookmarks Superusers are able to create a bookmark for the current Media Lister settings by expanding the "Add bookmark" field, entering a title for the bookmark, and clicking the "Add bookmark" button. Bookmarks will be visible to all users from the flyout menu. You can delete a bookmark from the module config screen. Module config In the module config screen you can define defaults for controls such as media type, view mode, pagination limit and column visibility. You can also delete bookmarks from the module config screen. https://github.com/Toutouwai/ProcessMediaLister https://processwire.com/modules/process-media-lister/