BitPoet

The default URL would be http://yourwebsite.com/processwire/. If it was changed to something else at installation time, and you have access to the database, just look in the table "pages" for the row with the id "2". The value in the "name" column there equals the path to the admin page.

I wonder if @ryan was ever contacted about this. I've tried to come up with a scenario where the URL injection mentioned in the CVE can become exploitable, but I'm having a hard time. When you can intercept a communication to that level and modify the message body, you could just forge the necessary requests, supply them with the intercepted session information and use the built-in module upload functionality. That's why we have DANE, so the communication stays confidential even if you're routed through untrustworthy networks. I've sent a rejection request to MITRE with the following rationale:

Comments.php isn't loaded automatically. It's only included when FieldtypeComments is loaded. The quickest way to access all the auxiliary classes for this fieldtype is to load the module by calling $modules->get('FieldtypeComments');

When you use file_get_contents with the filename property, there won't be an extra http GET, as it will recognize the local path and use regular file system IO. It's only when the argument to file_get_contents starts with a protocol schema indicator (http(s):// etc.) that it uses the network wrapper.

It worked, but it's a pretty roundabout way to go about it, as the server performs a http GET for the SVG to retrieve its contents. But my bad, path is the wrong property. Try "filename" instead.

It should be $content->images->eq(0)->path since file_get_contents operates on the local file system.

I'm a bit of two minds on that, as there might be a use case for empty repeater items. Nevertheless, it wouldn't hurt to point this out in the API docs. Perhaps open an issue in processwire-requests?

Thanks for letting me know. I've created an issue and will take a look as soon as I find a quiet minute.

Another vote for a page multiselect, with a label format of "{parent.title}: {title}" and a sort of "parent.title, title" to make things easy to see in the backend. As for grouping by sections, this might perhaps help you:

That's an nginx error. You need to increase the client_max_body_size setting in nginx.conf.

I really don't think the problem is within the module code. Are there any messages when you do a Modules -> Refresh? Do you have another module active that accesses simpleSearch? Additional idea: a debug_backtrace from within the constructor might be able to shed some light on it if it's really a case of the module being blocked from uninstall because it's in use.

After a quick glance, I don't think so. Have you tried writing into the PW log from ___install and ___uninstall? This should at least tell you whether uninstall+install happen. In the later case, you should also see the page request that triggers the re-installation. Just to make sure: you have $config->debug enabled so you don't miss any warnings, right?

You'll probably find either the full code or at least an include directive or module invocation in the page's PHP template file in site/templates. It's usually home.php for the start page, but if this differs from a default installation, you can look the name up in the template's configuration in the backend on the Files tab. If that is empty, the template file is named the same as the backend template.

To me it looks like renderRepeaterLabel is also called for a dummy repeater item (see the call with a NullPage here). That one doesn't have a page associated yet, as it hasn't been saved. It's just used to render the form for adding a new one. So the calls for the existing items succeed, but that last one fails and throws the error. This can be cured easily by adding a check for $page in the hook: // Get values of arguments sent to hook (if needed) $label = $event->arguments(0); $cnt = $event->arguments(1); $page = $event->arguments(2); // Only execute the hook for actual repeater items, // not for blank placeholders if($page instanceof NullPage) return; // Your code here, perhaps modifying the return value // just a simple test: $return = "LABEL " . $page->getForPage()->template(); In a short test, this worked like expected.

Did you activate page numbers for your template?

To create a new field, you need to select a Fieldtype, not an Inputfield. Fieldtypes often have a matching Inputfield, but some support different Inputfields to faciliate the input. The Fieldtype is the part that takes care of storing and loading the data for the field, while the Inputfield provides the UI for entering that data. In the case of InputfieldTextTags, it doesn't have a matching FieldtypeTextTags, but rather complements the existing Fieldtypes FieldtypeText, FieldtypePage and FieldtypeOptions. So you need to create one of those and then, when you configure the field, choose "Text Tags" as the Inputfield of choice. Once you save it, you will see the configuration options specific to InputfieldTextTags.

Does that happen with the regular backend login or some frontend login mechanism? In the later case, is the login done with LoginRegister?

Sometimes, you want to search a text field by the length of its content. FieldtypeText doesn't provide this functionality (yet). It's possible to add the necessary SQL to a query by hooking into PageFinder::getQuery like @bernhard pointed out here, but that's of course not really straight forward. There's also an open feature request for FieldtypeText in processwire-requests. FieldtypeTextWithLength is an extension of FieldtypeText, so you can switch your field's type between the two without loosing any information. After switching your field to "Text with .length Selector", you can search by the (character, not bytes!) length of the content: $pagesWithShortHeadlines = $pages->find('headline.length<10'); You will also find a new "Length" subfield when using Pages -> Find in the PW backend:

I brushed up my snippet with a ___getSelectorInfo method, so Lister & Co. can offer Length as a numeric subfield and put the module on GitHub.

Thanks! Appreciated! ? about it, in times of utf8(mb4) one might want to use CHAR_LENGTH instead of LENGTH. The first one counts the code points, i.e. visible characters, while the latter returns the bytes. LENGTH('?') is 4.

A short&quick&dirty module that adds .length (switching back and forth between regular Text fields and "Text with .length Selector" should not cause any troubles): <?php namespace ProcessWire; class FieldtypeTextWithLength extends FieldtypeText { public static function getModuleInfo() { return [ 'title' => __('Text with .length Selector', __FILE__), 'summary' => __('Like FieldtypeText, but with a subfield selector .length for string length comparison', __FILE__), 'version' => '0.0.1' ]; } public function getMatchQuery($query, $table, $subfield, $operator, $value) { $database = $this->wire("database"); if($subfield === 'length') { $table = $database->escapeTable($table); $value = $database->escapeStr($value); $query->where("LENGTH({$table}.data){$operator}$value"); } else { parent::getMatchQuery($query, $table, $subfield, $operator, $value); } return $query; } }

The problem I have is that the focus event isn't triggered for inline datepickers, which are especially handy if one wants to avoid invalid manual input. I've nevertheless thrown together a small POC module I've called DatePickerExclusions that works with focus and button click options. It still needs an option for time windows.

PageImage::removeVariations takes an associative array of options as its argument, which in turn is passed on to PageImageVariations::remove and PageImageVariations::find. The docs for the latter say (irrelevant parts snipped): /** * @param array $options Optional, one or more options in an associative array of the following: * - `width` (int): only variations with given width will be returned * - `height` (int): only variations with given height will be returned * - `width>=` (int): only variations with width greater than or equal to given will be returned * - `height>=` (int): only variations with height greater than or equal to given will be returned * - `width<=` (int): only variations with width less than or equal to given will be returned * - `height<=` (int): only variations with height less than or equal to given will be returned * - `suffix` (string): only variations having the given suffix will be returned * - `suffixes` (array): only variations having one of the given suffixes will be returned * - `noSuffix` (string): exclude variations having this suffix * - `noSuffixes` (array): exclude variations having any of these suffixes * - `name` (string): only variations containing this text in filename will be returned (case insensitive) * - `noName` (string): only variations NOT containing this text in filename will be returned (case insensitive) * - `regexName` (string): only variations that match this PCRE regex will be returned */ So ["width" => "201"] should work (untested though).

It does if you pass a filter function to the beforeShowDay option, though I haven't found a way to set that without modifying InputfieldDatetime.js.

This is great! Just a tiny nitpick: I'd swap around the logic for "Don't allow selection in both directions" and get rid of the "Don't", or maybe change it to "Disallow". It's a very cultural and regional thing whether questions with a negation get answered with a yes or no to confirm then, and it's bitten me in the backside myself when I rolled out an app with such a toggle to our international employees.