Short description of the enhancement

Extend InputfieldSelect to allow modification of the attributes of options added to the select.
Reference old issue here.

Why? This can already be done via the API, right?

When adding your own select options via the API (eg, when populating a select field in a module config) you can do this already (as pointed out by Ryan here.)

What you can't do, is easily extend the attributes on select options added by other peoples' code (eg. the core, or other modules.) This is what I want to be able to do.

Current vs. suggested behavior

Currently, when editing a page in the admin interface, the attribute options rendered by the core are 'value' and, potentially, 'selected'. Making the addition of options "hookable" allows this range of attributes to be extended, especially with the data-xyz family of attributes.

There's an example hook implementation that would allow this, here.

Why would the enhancement be useful to users?

Additional attributes on the options can be used in many ways with a suitable sprinkling of js to help. Here are a couple of examples...

Here, Macrura wanted to display the description field from the linked page when an option is selected.

I needed to create a select field that allowed the selection of sessions a gymnast could register for at our club - disallowing them from being selected into two groups that ran at the same time. I wanted to use a little js magic and a hook that would allow the addition of data attributes for sort order and day-starttime to the option - but I found no easy way to do this. In the end I had to develop a new ASM-derived inputfield.

Screenshots that demonstrate what could be more easily achieved with the enhancement

This is a repost from the wishlist & roadmap section of the forums:

One of PW 3.010's major novelty was the introduction of Horst's new image resizing engine that uses ImageMagick. Now I understand that ImageMagick can convert images to Webp, the image format that Google says can reduce image size up to 34% compared to JPEG.

Mozilla is adding support to Firefox, and even the Safari team is playing with it, so it looks like Webp is soon going to be available in most major browsers. If Horst's module can be extended to add Webp conversion, that would be a great addition to PW's already very powerful image manipulation arsenal.

I'm currently using the free ImageEngine Lite to serve Webp images to supporting browsers, and the results are impressive. I routinely get images that are between 25 and 60% smaller compared to JPEG, with the same visual quality. I would love to eliminate the need to rely on a third-party service though.

Hello @ryancramerdesign

I used to modify the index.php file to customize all the project's site paths.
In version 3.0 the code has been moved to Processwire::buildConfig($rootPath, $rootURL = null, array $options = array()).

Would it be possible to restore that possibility using the $options parameter for all other siteDir subdirs? Do you plan to do it?

kind regars
maks feltrin

Short description of the enhancement

InputfieldSelect does currently not have a public method (InputfieldSelect::getOptionAttributes) of getting/setting the additional attributes of options. Therefore additional attributes (e.g. asmselect) are not editable in hooks.

Why would the enhancement be useful to users?

I'd like to add additional info to the FormBuilder Fields overview and it's not possible like that.

Short description of the enhancement

Ability to use multilanguage fields in module config settings.

Why would the enhancement be useful to users?

I think many modules could benefit from the ability to define multilanguage versions of text. Forum post here: https://processwire.com/talk/topic/5825-multi-language-support-for-module-config-fields/

Would it be simple enough (ish) to store the different language versions in the module json paired to the id of the language?

Short description of the enhancement

Add a $config property that allows to add SQL commands to be performed on every database connect.

Optional: Steps that explain the enhancement

In WireDatabasePDO::getInstance and Datebase::__construct, check if a property $config->dbInitCommand is set. If yes, merge this after the builtin SET NAMES '$charset' command passed as with a semicolon.

Current vs. suggested behavior

Currently, only the set names statement is executed for each connection, and there's no means to add SQL code to that (at least that I know of).

Alternatively, hard-coding a set timezone command that sets the connection timezone to PHP's value might be a viable solution too (and even make sense to keep consistence when migrating between systems with different settings), but that might be breaking change for upgrading existing installations.

Why would the enhancement be useful to users?

I'm currently working on a module to enhance selectors for datetime fields. To work reliably, the MySQL connection needs to be aware of the timezone used by PHP (set time_zone = 'TIMEZONE-OF-PHP'). This can only be assured if the set time_zone command is executed for every connection.

Since the performance impact of such a change should be negligible and there is no hook to accomplish this, and there is definitive interest in my module (see module announcement and initial discussion), I'm hopeful this change can be incorporated.

Thanks for taking the time to read and think through this.

PW3 added link abstraction to text areas https://processwire.com/blog/posts/processwire-3.0.6-brings-pages-upgrades-and-link-abstraction/#new-link-abstraction-features.

Can we also have that for URL fields?

Note: this would only affect internal links in URL fields.

Current vs. suggested behavior

Currently links to internal pages in URL fields would break if a page is moved. If the url fields had link abstraction, pages could be moved without worrying about the values in URL fields breaking.

Non-superusers can edit the 404 page if they figure out a way to navigate to that edit page, but this page isn't visible for them on the page tree. I don't see a good reason to not properly display the 404 page for them, while I can think of a couple of pretty good reasons (in my opinion) to display it:

• In our case the clients control all their content, but don't have access to a superuser account, as that would give them access to certain features not intended for "content editors". This means that we have to either specifically provide a link to the 404 page edit screen or, more likely, that edit requests have to go through us (which is a waste of time for everyone involved).
• The 404 page could well be seen as one of the most important pages on a site (you get sent here every time you follow a dead link, try to guess an URL but fail, etc.) and those working on the content of the site (content editors) should always make sure that it serves it's purpose. Since the 404 page isn't visible on the page tree it's all too easy to miss and forget.
• Not seeing an editable page on the page tree is confusing and leaves the impression that perhaps there's something wrong with the permission model of the site. It's simply not in line with how the page tree usually works, and every time you stumble upon something like that it makes you trust the underlying system a bit less: "if this doesn't work as expected, how can I trust that everything else does?"

This request was originally posted at ryancramerdesign/ProcessWire#809. Reposting here since this is still causing confusion and now, almost two years later, I still feel that the current behaviour doesn't make sense.

Add arrayColumn() method to wire array API

I sometimes find PHP's arrayColumn() function useful and I extend WireArray with it using a hook. Could it be added to the core class?

Here's the code I use to add the arrayColumn() function.

/**
 * Extend WireArray to allow the fetching of all field values of a given name.
 * Designed to be similar to PHP's arrayColumn()
 */
$pages->addHook('WireArray::arrayColumn', function($event) {
    $column = $event->arguments(0);
    if (empty($column)) $column = 'title';
    $result = array();
    foreach ($event->object as $s) {
        $result[] = $s->$column;
    }
    $event->return = $result;
});

Current vs. suggested behavior

Current behaviour is fine but requires the use of hook extension of the base class.

Why would the enhancement be useful to users?

Would allow pulling a column of values from wire array results without having to use a custom hook.

$related_names = $repeater->people->arrayColumn();

https://processwire.com/talk/topic/11845-date-time-field-not-showing/

Not sure if there are any advantages to using date() at all anymore, but at least for the datetime field I think it should start using DateTime() so users can enter dates before 1901.

This is copied over from: ryancramerdesign/ProcessWire#1624

Short description of the enhancement

Allows developers to run their functions if a field hidden state is changed (in a showIf context).

Current vs. suggested behavior

There's only $(window).resized event at the moment which makes it hard and inefficient to work with.

Why would the enhancement be useful to users?

Eg. module developers can add their custom function, for example setting CKEditor plugin settings.

Pull request: processwire/processwire#16

At https://processwire.com/docs/install/new/ in the Requirements section is written "A web server running Apache.". I think it would be good to mention that PW can also run on other web servers/platforms, although not officially supported.

I was surprised to learn that InputFieldPassword does not allow whitespace*. I'd strongly recommend allowing them since I'm not aware of any technical reasons for the restriction.

* My PW password has had whitespace for a while, so at first I thought maybe the code changed. Then I remembered I had forgotten my password and reset it via the API, which doesn't have the whitespace restriction. Only today did I go in to change a password via the admin. :]

Short description of the enhancement

Rename Delete Tab to Trash on the Page Edit form

Why would the enhancement be useful to users?

It seems inconsistent to call the tab "Delete" when it actually just moves the item to the trash. The page list action button is called Trash, so I think this should be changed to match.

There has been some related discussion this morning starting here: https://processwire.com/talk/topic/13389-adminonsteroids/?do=findComment&comment=130537

Good day!

I always look for a way to minimize the amount of fields in my PW installation, reuse them as much as I can. Template context help me a lot, but not with images.

This update made it possible to override more options in custom fields. Why not allow more options to override for core fields?

It would make image fields much more reusable, if we could override these options:

• Maximum Files Allowed,
• Formatted value,
• Min and Max Image demensions

The more the better) Is there anything preventing this?

Briefly describe the enhancement or the feature request.

Allowing the reuse of arbitrary selectors as custom selector properties.

Considering a projects website, where old projects a archived under a different parent than active ones. One might often need to differentiate them even though other selectors are the same.

It would be nice if the selector could be stored somewhere:

isArchive => "template=projects, name=archive"

And could be used in a selector e.g. like this: "template=posts, parent=^isArchive"
which would expand to this: "template=posts, parent=[template=projects, name=archive]"

What is the current and suggested behavior?

Copy and paste the selector for each usage.

Why would the enhancement be useful to users?

Does allow users to avoid the need of duplicating selector parts.

This feature request comes from the old repository. It was originally opened in the forum and was written by @adrianbj.

Briefly describe the enhancement or the feature request.

Editors often forget or do not see that they have to publish the items/pages in a PageTable field. I think in many/most cases you would want all published automatically.

Or perhaps it could be an option for the field. The developer can decide whether editors can choose to save unpublished if they want.

Alternatively I think it would at least be helpful if there were publish and hide toggles (like the new main page tree action buttons) so it is easy to quickly publish all subpages rather than opening each one up.

I would prefer the first option though.

Why would the enhancement be useful to users?

It would prevent confusing users who miss to publish pages inside of a PageTable field, which happens quite regularly.

Short description of the enhancement

I think it would be helpful to add a page autocomplete to URL fields.

Briefly describe the enhancement or the feature request.

Allow for selectors to work with these: has_parent=1234|1235

What is the current and suggested behavior?

Currently only this does work: (has_parent=1234), (has_parent=1235).
The Selector parser could probably handle both cases by simply handling the shortform like the longer form.

Why would the enhancement be useful to users?

Sometimes one might to select pages from different branches in the page-tree

More information here: ryancramerdesign/ProcessWire#1232

Short description of the enhancement

Improvement for the workflow when setting internal links in CKEditor.

Current vs. suggested behavior

To use the Link button of CKEditor to set an internal link to a file on another page of the tree, you'd expect to do these steps:

• Mark the link text and click the Link Button
• Click Select Page
• Choose the wanted page from the tree
• Click Select File
• Choose the wanted file from the select list

But even when you have selected the other page, the select list of files would show just the files of the page you're on. To get the files from the other page you have to follow these steps:

• Mark the link text and click the Link Button
• Click Select File (but dont select anything)
• Click Select Page
• Choose the wanted page from the tree
• Click Select File (now you get the files from the other page)
• Choose the wanted file from the select list

I would propose a change here.

Why would the enhancement be useful to users?

This can be quite irritating for the editor users,

Carried over from ryancramerdesign/ProcessWire#2047

Feature Request: If possible one thing I would like to see is better consistency for replacing files in file and image fields. This is a task that content editors have to do constantly, so I would like to make it dead simple and obvious.

Here is some quick mockups:

For image fields:

When the "Replace Image" Button is clicked, a modal dialog pops up.

For File Fields:
Same thing...It opens a dialog to replace the file

What do you think? I'm not sure what it would take to code this, but I thought I would throw it out there in case someone is interested.

@rolandtoth also suggested this:
Adding a bigger file icon to the field could be used as a drag-and-drop area so it could work as in the new image fields:

Short description of the enhancement

Add an extra mime part for bodyHTML and body with type multipart-alternative at the same level as the attachments.

Current vs. suggested behavior

Current: since all parts are under a multipart-mixed header, they are treated equally. Most viewers will now display the plain text part and show the HTML part as an additional attachment or display both text and HTML bodies at once.

multipart-mixed
+---text/plain
+---text/html
+---attachment 1
+---...
+---attachment n

Suggested: instead of being directly at the multipart-mixed level, the HTML and text parts should have their own multipart-alternative part (with own boundary).

multipart-mixed
+---multipart-alternative
|   +---text/plain
|   +---text/html
|
+---attachment 1
+---...
+---attachment n

Why would the enhancement be useful to users?

Sending HTML mails with attachments is quite common.

An example can be seen in this discussion entry.

A fix for this is included in pull request processwire/processwire#19.

Short description of the enhancement

I'd like to see the strikethrough (unpublished) and faded (hidden) styling of page titles in the page edit breadcrumbs.

Current vs. suggested behavior

Currently unpublished and hidden pages have their titles in normal font styling.

Why would the enhancement be useful to users?

Just a nice visual cue/reminder about the status of the parents of the page you are currently editing.

vs

Briefly describe the enhancement or the feature request.

Repost of the old request: ryancramerdesign/ProcessWire#422
Plain sorting should be possible just by adding "template" => "template" to the options array in ProcessPageEdit:: buildFormSortfield.
The optional feature to sort in the order of allowed subtemplates might be a bit more work.

Why would the enhancement be useful to users?

Sometimes grouping by datatype is useful, even though pages share the same parent.

Short description of the enhancement

I think it would be very helpful if the javascript page name creation worked when changing the title on a recently copied/cloned page. This is only relevant for the standard copy mode (not ajax) which is invoked when copying a page with children.

Current vs. suggested behavior

Currently the name doesn't change from the "old-name-1" when changing the title. I think in this case since we are effectively creating a new page, it should change automatically to match the title.

Why would the enhancement be useful to users?

With the current behavior you have to manually edit the name to match the new title.

Short description of the enhancement

The fix for processwire/processwire-issues#28 makes PW automatically remove the ONLY_FULL_GROUP_BY and STRICT_TRANS_TABLES sql_mode settings when a new db connection is initiated. It would make sense to also do this for lower versions (MySQL 5.5, 5.6).

Current vs. suggested behavior

Currently, the "remove" option in $config->dbSqlModes for these properties defines the minimum applicable MySQL version as 5.7.0.

It would IMHO make sense to change the version number there to from 5.7.0 to 5.5.0.

Why would the enhancement be useful to users?

Both settings are already available in MySQL 5.5, and a good number of hosting providers now enable them by default, as e.g. seen in this forum discussion.

This is a request for advanced filtering in ListerPro.

ListerPro closes about 80% of needs for tabular data visualization (and editing). However it is not enough for "advanced" reporting. Feature that I miss is such kind of filtering: {myfield1.subfeild1.subfield1.date1} > {myfield2.subfeild2.subfield2.date2} - with indefinite levels depth, fully customizable on left and on right sides of condition, even with PHP snippets option.

Also, few minor requests for ListerPro setup:

• add colums width customization
• add bookmark title to understand "which bookmark I am currently viewing"
• add InputfieldLister module for use in custom pages

Briefly describe the enhancement or the feature request:

ProcessWire currently allows you to exclude files from compilation via the exclusions config property. However, this isn't helpful for modules. In my case, I am developing Jumplinks 2, and have opted to bundle a vendor directory with the module itself so I need not rely on the root composer.json and vendor to autoload my dependencies. The main issue with doing so means that an extra module installation step is needed, which I'd like to avoid.

It would be spectacular is ProcessWire modules could define a module info option, similar to the config option described above, but relative to the root of the module. So, for example, in a module's JSON file or related method, I would include the following (or something along the lines of) to prevent compilation of anything inside the vendor directory:

{
    ...
    "fileCompilerOptions": {
        "exclusions": ["vendor"]
    }
}

That exclusion would then internally map to the following, in my case, and add to the global exclusions array:

D:/<root>/site/modules/ProcessJumplinks/vendor

Note: Using / here as PW converts to this anyway.

Why would the enhancement be useful to users?

In this particular instance, certain non-namespaced files that get copiled could cause unintended side effects. For me, vendor/illuminate/Support/helpers.php was being compiled as it is not namespaced, and class_parents was being converted to ProcessWire\wireClassParents, which is something not specific to the context of the compiled file.

Having looked through FileCompiler.php, I see the same would occur for class_implements and that, too, could cause unintended side effects.

This is useful for developers who choose to have vendor directories inside their module packages and don't want to worry about these side effects, which could pop up at any time.

The reason this should be specified in the module info declaration is due to the fact that I should not expect my users to manually add the exclusion to their site config.

Is there an alternative to this enhancement?

As this issue may only be valid for vendor directories, a more suitable alternative would be to add "fileCompiler": { "excludeVendor": true } to the module's info declaration, thus not needing to declare specific directories.

However, we should give consideration to those who have dependencies stored in different directories, such as lib.

Edge-case?

This could well be seen as an edge-case, specifically in reference to the methods being converted. Nonetheless, I think it is wise to give the developer the choice to make these exclusions on a per-module basis.

Short description of the enhancement

I'm using a custom Pagefiles implementation which enhances FieldtypeFile for cloud provider stored files. Now running isTemp() (run by formatValue()) on each file for each request is quite a task for a file stored somewhere in the cloud. By now I've simply disabled the check, but maybe there can be a core change, so that temp. files are not even part of the field value until they are saved. Maybe saving the temp. status to the db could be an option, too.

Current vs. suggested behavior

Temp. files added to the field value and checked by timestamps on file vs. external tracking of temp. files.

Why would the enhancement be useful to users?

Files might not always be cheap to check for creation/modify dates.

Hello @ryancramerdesign ,

something (the language part) I already discussed a while ago (maybe 2-3 years ago).

A couple (well ok... 4) of features I would like to see in the readmap of pw are:

1. no language page names in the backend. In my opinion there iso no need for multilingual url separation in the admin area (like it's done for the user template pages).
2. decoupling interface languages in frontend/backend. a quick example:
   fr_FR interface in the backend
   en_US, de_DE (with multilinguagl page names) in the frontend
   ...and of course the backend will still need to be able to update frontend multilingual fields of pages
3. separation of frontend/backend applications. The point is for instance being able to add another layer of authentication via http auth for the admin entry script and disabling admin processes access from the frontend application
4. separation of code from public assets: of corse we block access to important files via apache rules but it's always safer having all the server code outside the public docroot. I usually like to have only the 2 entry scripts and the captcha generator script in the public dir.

kind regards.

Short description of the enhancement

A button (or similar) that would open/close all repeater items at once. Maybe this might be a problem on a page with a LOT of items? Maybe repeaters should be the next fieldtype to support pagination?

Why would the enhancement be useful to users?

Page load is obviously more efficient with items collapsed by default, but if you are using items as a content block builder (especially in RepeaterMatrix) it can be hard to get an idea of the content of entire page without expanding them all.

Conversely, if you choose to have them open by default, it can be difficult to reorder with long blocks or lots of items, so being able to collapse all quickly would be very handy.

Short description of the enhancement

Currently, long mail subjects get passed to PHP's mail() function unchanged, which leads to subjects exceeding the 76 characters limit set in the RFCs being displayed truncated in most email viewers.

Optional: Steps that explain the enhancement

1. Call $mail->subject() with a subject around 100 characters
2. Call $mail->send()
3. Watch mail in different viewers

Current vs. suggested behavior

Currently, the subject is passed through unchanged. It should be wrapped according to the applicable RFCs.

Why would the enhancement be useful to users?

The problem popped up in the discussion about UTF8 support.

A fix for this is included in processwire/processwire#19.

Short description of the enhancement

Add an admin interface to manage redirects, made by Page Path History.

Why would the enhancement be useful to users?

Something alike already exists, but I think the core module is incomplete without such interface. There is actually no way to control these redirects. And lots of redirects is not a good thing.

There are several roles that work with page and I have to remind them about queue in order to ensure that edits are saved properly. It is not effective. To unlock the capability, all fields and even admin layout should be able to update in "real-time" as soon as there are changes at server + there should be field-level lock/sync mechanism.

Currently, you can only create a bookmark if the page is a standalone page in the page tree. Very helpful would be if the module configurations could also create as a bookmark. Eg to the module: processwire/module/edit?name=MarkupSEO&collapse_info=1

I ask this again here in the new format. The old request is [here](Considering directly comparable functionality has already been implemented on other repeater-like fields. Would really like to see this.).

Briefly describe the enhancement or the feature request.

Not having the ability to specify a maximum number of items has caused problems for us with clients. Considering directly comparable functionality has already been implemented on other repeater-like fields, can we not replicate the behaviour of those and implement it for repeaters.

What is the current and suggested behavior?

Just to limit the number that are output on the front-end.

Why would the enhancement be useful to users?

Perhaps it doesn't matter when us developers are adding in content, but a lot of our clients like to add content themselves, and sometimes they even require training on how to add content ProcessWire. ProcessWire is extremely easy to use when just editing content, but that is from the perspective of someone who is technically adept. A client just see buttons and form elements they can click that just "do" different things. A lot of clients don't read instructions (let alone any emails sent to them), and just try things and come back to us when it "doesn't work".

One client didn't realise you had to click on the little "Select" button next to the page title when interacting with a Page field to actually select the page, and then wondered why it was still linking to a different page.

@ryancramerdesign, I know you are against the idea of this. But this has already been implemented for files/image fields, and in an abstract sense, they are functionally identical.

Applying a limit more than the current number of items in the repeater after creation doesn't necessarily have to incur the automatic destruction of data. The repeater items can just stay there (but won't be output on the front-end), and a warning can be shown to the user saying that any excess repeater items will not be shown.

Briefly describe the enhancement or the feature request.

Unselecting pages in page-list inputfields is just a UX nightmare, because no inexperienced user will find out how to do it.

Optional: Do you have screenshots/links that demonstrate the enhancement?

Integrate bernhards module into the core: https://processwire.com/talk/topic/11805-pagelistselectunselectbutton/#comment-109780

Repost of: ryancramerdesign/ProcessWire#438

In some situations I'd find it very useful to be able to define an array of field names to trigger the expiration, rather than a page selector. So if there was a change to the content of the defined field(s) on any page/template, the cache would expire.

It might be a nice addition to optionally also limit to changes to these fields on specific pages/templates.

Copied over from: ryancramerdesign/ProcessWire#1384

Short description of the enhancement

I'd like to suggest adding Symfony Var_dumper globally, in the standard Processwire install. Var_dumper will help us developers and module authors alike to debug variables/objects output.

Current vs. suggested behavior

Currently, we use var_dump($var) to output variables/object for debugging purpose.
Once Symfony Dumper is added, we can use dump($var) to achieve the same task.

Why would the enhancement be useful to users?

Symfony Var_dumper will format arrays and objects and make them prettier and easier to read. I think developers and module authors will enjoy this addition.

Optional: Screenshots/Links that demonstrate the enhancement

Output using Symfony Var_dumper

Output using PHP's var_dump()

Can you add an option to image fields to require the alt attribute and have it enabled by default? This would help make sites everywhere more accessible and help improve SEO.

Drupal 8 adopted this change here https://www.drupal.org/node/2303765

Here is what it looks like in Drupal 8:

Maybe the CKeditor wysiwyg editor's page image editor could also automatically prefill the alt attribute from the chosen image as default that can be optionally overridden?

Short description of the enhancement

Double-clicking on one repeater item would flag all for deletion, the way that files / images work.

Current vs. suggested behavior

Currently you have to delete one at a time

Why would the enhancement be useful to users?

I think this is now more important given that a page can now have many more repeater items than before (now that they can be ajax loaded).

Short description of the enhancement

The repeater template and its Admin > Repeaters parent should be renamed to match the new field name.

Current vs. suggested behavior

The current behavior results in repeater templates named the same as the original repeater field, and its parent page also with the original field name, eg. Admin > Repeaters > original_field_name

Why would the enhancement be useful to users?

I think it's one of those consistency things that should be cleaned up. It could also be quite useful if you end up with a corrupted db and need to manually cleanup a repeater field and its template and parent page.

Would it be possible to make the renderReady function in Inputfield Core class hookable?
https://github.com/processwire/processwire/blob/master/wire/core/Inputfield.php#L1030
I could not find another way to add Javascript or CSS to Inputfields when the Inputfield is loaded via Ajax (Repeaters or loadedByAjax).

More info here on my forum post:
https://processwire.com/talk/topic/14187-inputfieldrenderready-hook-alternative/

I think it would be useful if someone doesn´t actually want to add/extend an existing inputfield, but only add some special additions to the existing via hooks. I personally would need it for a module that adds another kind of upload tool to the current InputfieldImage. (PlUpload). I need to add some JS and CSS.

Perhaps there is another way of doing such things, but I could not find any till now?

Thank you!

Short description of the enhancement

Support wrapping long text (without spaces) in logs using CSS word-wrap: break-word; on the table cell.

Optional: Steps that explain the enhancement

N/A

Current vs. suggested behavior

Viewing logs in the admin with long text (e.g. long query strings) stretches the table wider than the browser and causes left-right scrolling. Instead it should wrap these long lines.

Why would the enhancement be useful to users?

Easier to skim through logs if all information is visible without left-right scrolling.

Optional: Screenshots/Links that demonstrate the enhancement

N/A

Current vs. suggested behavior

Currently there is an undocumented feature that allows the options of a Page inputfield to be limited by the value of another Page inputfield on the same page, by using a reference to the first Page field in the "Custom selector to find selectable pages" setting of the second Page field. But this feature only works Select, Select Multiple and AsmSelect inputfield types.

It would be nice to be able to use the same feature for Radios and Checkboxes inputfield types. Support for Autocomplete would be amazing, but probably a tougher nut to crack.

Why would the enhancement be useful to users?

The dependent fields feature is great, but sometimes you want radios or checkboxes :)

I don´t know if this was requested before.
I think Processwire will benefit if the installer
could be translated in other languages beside english.

Maybe using the native php gettext http://php.net/manual/en/book.gettext.php
or https://code.launchpad.net/php-gettext
just for the installer part. Then using Po and Mo files
will enable translation in other languages.

👍

Copied over on request from
ryancramerdesign/ProcessWire#1230 (comment)

Not sure this has been mentioned before:
If I clone a template, the field overrides (labels, look and behavior) set in the source template get all lost in the template clone, so it is not a real clone. It can be a source for errors if I forget to fix the fields and it is a bit tedious to go through all the fields to update them manually sometimes.

Briefly describe the enhancement or the feature request.

Inputfield dependencies should be constructed via the built-in lister, instead of the current plain text field.

What are the steps that explain the enhancement?

1. Go to the settings of a field.
2. Open the tab „Input“.
3. Click on either „Show this field only if“ or „Required only if“.
4. The lister appears (similar to the one under „Pages“ ➡️ „Find“ ➡️ „What pages to show“).
5. The user selects the field-value-pairs he/she wants and saves the page.

What is the current and suggested behavior?

Currently users enter the field names in a text field:

The equivalent with the lister would look like this:

The first dropdown (with selected „repeater_list“) lists all available fields.

Why would the enhancement be useful to users?

I think it’s a better and easier-to-use approach to select available fields as inputfield dependencies. It would also make situations, where the user wants to delete a field, more robust and fail-save: ProcessWire could programmatically check if such a field has been used as an inputfield dependency and could prevent the user from deleting the field (or show the user a warning).

Briefly describe the enhancement or the feature request.

It would be great if the pagination and API-side sorting and filtering that is now possible on the Table field (and is planned for File and Repeater fields) also worked for Page fields.

What is the current and suggested behavior?

Currently an operation like $page->my_page_field("limit=10, sort=title") gives an error. Suggestion is that Page fields support this.

Why would the enhancement be useful to users?

It would avoid having to load the entire Page field PageArray into memory in order to sort, filter or iterate over it. Having pagination features for Page fields in the admin would allow Page fields to be used for larger numbers of selected pages than is currently practical.

Short description of the enhancement

Support custom fields for images. ImageExtra module provides this functionality, but it would be great to support this in the core for a more seamless experience.

Current vs. suggested behavior

n/a

Why would the enhancement be useful to users?

Oftentimes, custom fields are needed for an image. Of course, one way around this is to make a repeater that contains an image field with the needed custom fields, but then you lose the nice UI that PW provides for images.