Short description of the issue

Strikethrough disappears when hovering on an unpublished repeater item

Expected behavior

The background of the repeater item header bar should darken (as it does), but the line-through should remain

Actual behavior

The line-through is removed. Not a huge deal, but just another weird inconsistency.

Optional: Suggestion for a possible fix

I would send you a PR, but I know for this small stuff you find it easier to do manually.

Briefly describe the issue.

Getting "ProcessWire: ProcessPageEditImageSelect: Page is not editable" when i click on "Variations" for image inside repeater for role with minimal permissions.

What did you expect to happen?

For ProcessWire to show the variations of the image.

What did actually happen?

Got the error "ProcessWire: ProcessPageEditImageSelect: Page is not editable"

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

What are the steps to reproduce the issue?

1. Create an image field
2. Create a repeater
3. Add image field to repeater
4. Create a template
5. Add repeater to template
6. Create page using template, create repeater item, upload image.
7. Create a role
8. Assign minimal permissions to the role/template that just allow for the creation/editing of content
9. Create a user using the role
10. Log into the user
11. Edit the page
12. Click on the "Variations" button for the image inside the repeater

Tell us about the setup you experienced the bug in.

• ProcessWire version: 3.0.34

This happens on multiple environments (local, staging, production) which are difference servers

Short description of the issue

Array to String Conversion line 135 of WireLog.php

Expected behavior

No error

Actual behavior

The above error

Optional: Suggestion for a possible fix

I think this might be a new error with PHP7 not interpreting $option[delimiter] correctly.

$text = "$url$options[delimiter]$text";

You might also want to fix line 140:

$text = ($user && $user->id ? $user->name : "?") . "$options[delimiter]$text";

Short description of the issue

When you upload an image via the CK editor upload function, it creates an entry in the database for this uploaded image, but with a wrong datetime

Expected behavior

"created" datetime of newly uploaded files must be current time.

Actual behavior

"created" datetime is wrong, like "1970-01-01 01:00:10"

Optional: Screenshots/Links that demonstrate the issue

Steps to reproduce the issue

1. Upload a new image via CK Editor popup, to any image field
2. look into the database and check the datetime of this newly uploaded image

Setup/Environment

• ProcessWire version: 3.0.35
• (Optional) PHP version: 5.6.25
• (Optional) MySQL version: 5.6.28
• (Optional) Any 3rd party modules that are installed and could be related to the issue: CK Editor

Short description of the issue

The PageAutocomplete inputfield shows (and allows selection of) pages that are disallowed by the custom selector defined for the field.

This is my custom selector...
id!=page.id
...and the current page is still selectable in the inputfield.

Expected behavior

Inputfield does not show pages that are disallowed by custom selector.

Actual behavior

Inputfield shows and allows selection of the disallowed page. When the page is saved there is no warning, but the value of the disallowed page is not stored in the field.

Steps to reproduce the issue

1. Create Page field using PageAutocomplete inputfield, with custom selector set to id!=page.id
2. In Edit Page, try selecting the current page in the PageAutocomplete inputfield.

Setup/Environment

• ProcessWire version: 3.0.35
• PHP version: 7

An SQL error appears when you create an "Options" field.

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'XXXXX.fieldtype_options' doesn't exist

Steps to reproduce the issue

1. Install a blank version of Processwire 3.0.35
2. Install the core module "Select Options"
3. Create a field named "season" and type "Options"

Setup/Environment

• ProcessWire version: 3.0.35 (master)
• (Optional) PHP version: 7.0.11
• (Optional) MySQL version: 5.5.52 (MariaDB)

Short description of the issue

Using a custom selector to find selectable pages not working with user roles.

Expected behavior

Pages are selected and shown for field page type and saved.

Actual behavior

Pages are selected and shown for field page type, but cannot save.

Optional: Screenshots/Links that demonstrate the issue

Attempts include:
Error saving field "rider_account" - Page 1029 is not valid for rider_account (Page 1029 does not match findPagesSelector: template=user, roles.name=rider)

Error saving field "rider_account" - Page 1029 is not valid for rider_account (Page 1029 does not match findPagesSelector: template=user, roles=rider)

Optional: Suggestion for a possible fix

Work around is to use PHP custom selector:
return $pages->find("template=user, roles=rider");

Steps to reproduce the issue

1. Add user roles
2. Create field page type with custom selector: template=user, roles={user role}
3. Add field to page template, and attempt to save page.

Setup/Environment

• ProcessWire version: 3.0.34
• (Optional) PHP version: 5.3
• (Optional) MySQL version: 5.1.73
• (Optional) Any 3rd party modules that are installed and could be related to the issue:

Steps to reproduce with a recent devns clone:

1. Add a field of type 'Page' to a template.
2. Configure its input field type to 'Select Multiple'
   
3. Uncheck 'Allow unpublished pages?'
4. Unpublish one of the eligible pages, e.g. 'Child page example 1' from the stock basic site profile.
5. Create a page using this template and find that 'Child page example 1' is not an available option
   
6. Configure the 'Page' field's input field to one of 'PageListSelect', 'PageListSelectMultiple', 'PageAutocomplete'.
7. Create a page using this template and find that 'Child page example 1' is an available option
   
   

I think this confuses users as the unpublished pages, while selectable, are not persisted when 'Allow unpublished pages?' is unchecked.

(This issue is a resurface attempt for ryancramerdesign/ProcessWire#1973, as suggested in #1)

Briefly describe the issue.

Trying to select a page by it's PageListSelect value does only present a select box with the first level of children in the InputfieldSelect filter and no way to deviate from those.

Repost of: ryancramerdesign/ProcessWire#1193

What did you expect to happen?

Either no select at all, a PageListSelect or at least the option to supply a id manually

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

https://www.dropbox.com/s/03etsgly7c0s6e4/Screenshot%202016-10-01%2011.14.13.png?dl=0
https://www.dropbox.com/s/m5ff2m92zrut7no/Screenshot%202016-10-01%2011.14.39.png?dl=0

What are the steps to reproduce the issue?

1. Setup a page with a PageListSelect field and only a parent limitation to the page field.
2. Save the page with a chosen page deeper nested below the parent page.
3. Try to filter for just that page.

Tell us about the setup you experienced the bug in.

• ProcessWire version: 3.0.35

Briefly describe the issue.

The second time you click the save button, the field creation modal closes before you can adjust additional settings on the Input tab that weren't available until after the second save.

What did you expect to happen?

I should be able to save as many times as needed before adding to the template and closing the modal

What did actually happen?

Modal closes and adds the field, but I need to go back to fields to do final config.

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

Your screenshots/links go here.

Optional: Have you a suggestion for a possible fix?

processwire/processwire#11

Briefly describe the issue.

When you expand a branch in the page tree which has a parent which is "hidden", it is no longer lighter colored text once it has been clicked and its children are shown

What did you expect to happen?

I think it should have the yellow highlighter background, but still be the lighter color text

What did actually happen?

Text is dark, just like a normal, not hidden page

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

This can actually be quite annoying when you have a lot of expanded branches because you have to mouseover to check whether the action button shows Hide or Unhide to know its status.

Short Description of the Issue

When using Page Autocomplete with a Page field, with no restrictions or filters on the results, the user cannot add the home page. Typing "Home" in the field does make the page appear in the autocomplete menu, but choosing it does not add it to the list of selected pages.

Expected Behavior

Choosing the home page from the autocomplete menu should add it to the list of selected pages, just as it does for any other page.

Actual Behavior

When the user chooses the home page from the autocomplete menu, nothing happens. There are no javascript errors in the console.

Steps to Reproduce the Issue

1. Create a Page field with no restrictions or filters, using PageAutocomplete as the input type.
2. Add this field to any template.
3. Create a page using that template, and attempt to add the home page using that field.

Setup/Environment

• ProcessWire version: Confirmed in 2.7 and 3.0
• PHP version: 5.4.16

Forum thread: https://processwire.com/talk/topic/14398-selecting-the-home-page-with-page-autocomplete/

Short description of the issue

Error: strpos() expects parameter 1 to be string, array given on line: 96 in /Users/ajones/Sites/ecoreportcard/wire/core/PageComparison.php

Expected behavior

No error

Optional: Suggestion for a possible fix

This might be hard for you to reproduce - I am seeing it with a complicated API script and I haven't yet figured out what part of it is initiating this.

This is the array that is being returned:

array (2)
0 => "has_parent"
1 => "id"

Trouble is I am not sure if we should be figuring out why $property is an array in this situation, or whether it's ok to just check for an array and not proceed with trying to explode since it's already an array.

If you think we need to figure out why $property is an array, let me know and I'll try to isolate it.

Briefly describe the issue.

Page does not save content, but still sends a green "saved" response, if the template has a wrong order of fieldset and fieldset_END. That was one of my recent mystery bugs only in combination with a certain template. Somehow I must have inadvertently dragged the wrong field and ended with a wrong order.

What did you expect to happen?

Wrong order of a fieldset opening and closing field is not allowed or there is a warning.
Or a correction like we have it when a missing _END field is added.

What did actually happen?

I could save the template with my error in it. No warning, no automated fix.
The corresponding page opened as normal on editing but any changes to the content were not saved. The failure was silent, no errors, notices or anything.

Optional: Have you a suggestion for a possible fix?

I corrected the order of the fieldset after I discovered the issue and now PW behaves normal.
I cannot blame PW for it as it was the result of a mistake from my part but maybe that effect is interesting to know for you.

Tell us about the setup you experienced the bug in.

• ProcessWire version: 3.034 - live and localhost, on 2 different installs.
• (Optional) PHP version: 7-10

Briefly describe the issue.

TextformatterSmartypants transforms "dumb" typography into "smart" typography, encoded as HTML entities. But it doesn't convert all necessary characters to entities (e.g. >) so it often needs to be used in conjunction with TextformatterEntities. But this results in either:

• the double-encoding of ampersands (Smartypants before Entities)
• or dumb typography (Entities before Smartypants)

What did you expect to happen?

TextformatterSmartypants and TextformatterEntities are able to be used together with normal functionality for each textformatter.

What did actually happen?

• the double-encoding of ampersands (Smartypants before Entities)
• or dumb typography (Entities before Smartypants)

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

Bad:

Also bad:

Optional: Have you a suggestion for a possible fix?

The simplest fix would be to decode entities coming from Smartypants. In TextformatterSmartypants.module:

public function format(&$str) {
    require_once(dirname(__FILE__) . "/smartypants.php"); 
    // original
    // $str = \SmartyPants($str);

    // fixed
    $str = html_entity_decode(\SmartyPants($str));
}

Alternatively each entity in smartypants.php could be replaced with its UTF-8 equivalent.

What are the steps to reproduce the issue?

1. Apply both TextformatterSmartypants and TextformatterEntities to the same field, which contains dumb quotes.
2. Check the result of the textformatters on the front-end.

Tell us about the setup you experienced the bug in.

• ProcessWire version: 3.0.35

Updated from ryancramerdesign/ProcessWire#1684

Seems like the two broken links are now:
https://processwire.com/api/ref/classLoader/
https://processwire.com/api/ref/languages/

Short description of the issue

Umlauts (non-ascii characters) used in the body or subject of messages sent using WireMail appear mangled.

Expected behavior

Umlauts should display as entered.

Actual behavior

Umlauts display as two characters with their raw ascii representation.

Optional: Screenshots/Links that demonstrate the issue

See forum discussion

Optional: Suggestion for a possible fix

The text and html body parts should always be sent using quoted-printable encoding. This way, even old 7bit-only smtp server won't have any problems in accepting and relaying the mail. Other possible 7bit-compatible encodings like base64 obfuscate too much of the content for debugging purposes.

The subject line and the name parts in the from: and to: header fields should similarly be encoded using quoted printable, enabling the use of utf-8 characters there as well.

Pull request submitted as processwire/processwire/pull/17

Steps to reproduce the issue

See the examples in the forum discussion

Setup/Environment

• ProcessWire version: 3.0/dev

Short description of the issue

I get this error on the last step of the installation.

404 Not Found
Can't save page 41: /manage/access/users/benni/: Call $page->setOutputFormatting(false) before getting/setting values that will be modified and saved. [pass]

Expected behavior

Saving the password correctly.

Steps to reproduce the issue

1. Download PW
2. Install with blank template
3. Get to last step

Setup/Environment

• ProcessWire version: 3.0.36

ProcessWire 3.0.33

When editing a image using "Crop", pressing button "Save as Copy" does not work correctly but produce an empty broken image.

Short description of the issue

If I select "None" in the "Date Input Format" field in the "Input" tab while configuring a Datetime field, It reverts to it's default value when I click save.

Expected behavior

For it to maintain it's value of "None" after save, and then only be able to select a time using the Datetime field.

Actual behavior

It reverts to its default value of "2016-04-08".

Steps to reproduce the issue

1. Create a new field with type "Datetime"
2. Go to the "Input" tab
3. Set the value of "Date Input Format" to "None"
4. Click save
5. Notice how it's value is now "2016-04-08"

Setup/Environment

• ProcessWire version: 3.0.35

I'm guessing it's because the timestamp, when converted back into a human readable date would actually read "01-Jan-1970 5:10pm", which is obviously not correct.

It's not a big deal, it's just that it would be good if the Datetime input would could just contain a time, as I have a use case, and can think of more. For a site I am working on right now, we need them to be able to select a date, and then two times that are on the same date. And AFAIK, there is no in-built way to enforce those rules on two separate Datetime fields.

Perhaps a better solution might be to remove the "None" option from the field, and then create another field type which is capable of containing only a time, and that time would be represented internally as an integer between 0 and 86400. And then you could just add the timestamp from the date, and the mini-timestamp from the time, and have a complete timestamp?

Modal window moves up when closing (error/warning/message) messages in modal. The modal close button becomes unreachable.

• ProcessWire version: 3.034 and down
• behaviour in Chrome, other browsers not tested.

Briefly describe the issue.

When installing the Helloworld.module via the .zip upload it's creating a folder structure like this:

What did actually happen?

├── modules
│   ├── Helloworld.module
│   ├── Helloworld
│   │   ├── Helloworld.module

This way the updated module is never found even by doing a refresh.

Optional: Have you a suggestion for a possible fix?

I think putting the Helloworld.module in a folder is the most simple fix for such inconviencies, but as long modules are allowed without wrapping folder this should probably prevented or at least be noted to the user.

What are the steps to reproduce the issue?

Fresh installation and upload a updated Helloworld.module as .zip.

Tell us about the setup you experienced the bug in:

• ProcessWire version: 3.0.35

Short description of the issue

After updating to the latest master, I'm getting the following error trying to import fields:
Call to a member function setImportData() on a non-object (line 440 of /homepages/42/d264496819/htdocs/wire/core/Templates.php)

Expected behavior

The fields import.

Actual behavior

Error as above.

Steps to reproduce the issue

1. Export fields from another install
2. Try to import fields into new one
3. Error as above appears

Input data as follows:
{ "content": { "id": 230, "type": "FieldtypeTextarea", "flags": 0, "name": "content", "label": "Content", "textformatters": [ "TextformatterEntities" ], "inputfieldClass": "InputfieldTextarea", "contentType": 0, "collapsed": 0, "minlength": 0, "maxlength": 0, "showCount": 0, "rows": 5, "htmlOptions": "", "showIf": "", "columnWidth": 100, "required": "", "requiredAttr": "", "requiredIf": "", "stripTags": "", "placeholder": "" }, "pdf": { "id": 232, "type": "FieldtypeFile", "flags": 0, "name": "pdf", "label": "PDF", "extensions": "pdf doc docx xls xlsx gif jpg jpeg png", "maxFiles": 1, "outputFormat": 0, "defaultValuePage": 0, "inputfieldClass": "InputfieldFile", "descriptionRows": 0, "fileSchema": 2, "outputString": "", "textformatters": "", "entityEncode": "", "useTags": "", "collapsed": 0, "showIf": "", "columnWidth": 100, "required": "", "requiredIf": "", "unzip": "", "overwrite": "" }, "video": { "id": 231, "type": "FieldtypeFile", "flags": 0, "name": "video", "label": "Video", "extensions": "mp4 webm ogv ogg jpeg jpg", "maxFiles": 0, "outputFormat": 0, "defaultValuePage": 0, "inputfieldClass": "InputfieldFile", "descriptionRows": 0, "fileSchema": 2, "collapsed": 0, "outputString": "", "textformatters": "", "entityEncode": "", "useTags": "", "showIf": "", "columnWidth": 100, "required": "", "requiredIf": "", "unzip": "", "overwrite": "" }, "words_timeline": { "id": 229, "type": "FieldtypeTable", "flags": 0, "name": "words_timeline", "label": "Words Timeline", "maxCols": 2, "col1name": "words", "col1label": "Words", "col1type": "text", "col1width": 50, "col1sort": 1, "col2name": "delay", "col2label": "Delay", "col2type": "int2", "col2width": 50, "col2sort": 2, "col3sort": 3, "collapsed": 0, "col1settings": "textformatters=TextformatterEntities\nplaceholder=\ndefault=", "col1options": "", "col2options": "", "renameColumn": "", "showIf": "", "columnWidth": 100, "required": "", "requiredIf": "" } }

Setup/Environment

• ProcessWire version: 3.0.36

Briefly describe the issue.

On processwire.com - on the home page - there is a download button which says 3.0.34 and 2.8.34. But, on the actual Downloads, I'm only offered 3.0.34 and 2.8.33.

Short description of the issue

Log files often have htmlentities in the text

Expected behavior

Deleted field "linked_images_block" data in 0 row(s) from 0 page(s). [page-by-page] (Fields)

Actual behavior

Deleted field "linked_images_block" data in 0 row(s) from 0 page(s). [page-by-page] (Fields)

Optional: Suggestion for a possible fix

Not sure if it would be best to decode the entities in the log file itself (my preference), or decode when viewing via Setup > Logs

Short description of the issue

PHP 7 is throwing notices these now when trying to do math on non-numeric values.

Optional: Suggestion for a possible fix

Here's the current one:
https://github.com/processwire/processwire/blob/bac5b0de5d95b5a10c09f48ba5e63b419ee68799/wire/core/Pageimage.php#L680

I wonder if you'd like to keep this issue open and you can edit this post removing them as they are fixed and I can add more as I find them. Might be easier than a new issue every time I find a new one. Obviously not PR worthy, so up to you - how would be best like me to report / you to manage these?

Short description of the issue

I get these notices when the copy uses the ajax copy mode.

Steps to reproduce the issue

1. Click the copy page list action on a page with no children

Setup/Environment

• ProcessWire version:
• (Optional) PHP version:
• (Optional) MySQL version:
• (Optional) Any 3rd party modules that are installed and could be related to the issue:

How should we handle still open issues in the "old" ProcessWire repository? Should be migrate them step-by-step into this one? Any suggestions?

@ryancramerdesign I think it would be also good to add a READ THIS BEFORE SUBMITTING ISSUE REPORTS issue (like you did here) in the old repository.

Short description of the issue

Using $config->chmodFile for .sql files is a bad idea on some shared hosting environments.

Real world example

My Host recommends chmod 640 for .htaccess-, .html-, .txt and image files etc.
Therefore I've set $config->chmodFile = '0640';

When it comes to directories they suggest chmod 710.
Therefore I've set $config->chmodDir = '0710';

Now for PHP scripts (guess that also applies to SQL files) they suggest chmod 600.
Unfortunately I have not found any matching $config property for this case.

Conclusion

I think using chmod 640 for SQL files in this case is insecure and this needs to be fixed.

I'd even say ProcessDatabaseBackups, WireDatabaseBackup and all modules that rely on these must be considered insecure on shared hosting environments.

Solution

Make ProcessDatabaseBackups a ConfigurableModule.

OR

Introduce a new config property $config->chmodSensitiveFile and use this instead.

I think a new config property is better because of 3rd party modules that may rely on WireDatabaseBackup. (It may be helpful in other scenarios as well ...)

ProcessWire version: 3.0.35

Short description of the issue

Sorry, maybe this should be posted in the Table support thread, but it's the core Copy action that triggers, so went with here.

Expected behavior

No error

Actual behavior

Error saving field "cc_emails" - SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1' for key 'PRIMARY'

None of the rows from the Table field are copied to the new page.

Steps to reproduce the issue

1. Click the copy page list action button on a page that has a table field

Short description of the issue

$page->filesManager->getFile('some_image.jpg')

If the database entry for "some_image.jpg" has a created-datetime like "1970-01-01 01:00:10", it does not pass the validation and won’t get selected, even if the image itself would be perfectly okay to handle.

Expected behavior

Image gets selected and can be used as an image object.

Actual behavior

Return is NULL

Steps to reproduce the issue

1. Upload an image within CK editor (see #41)
2. in the template, try $page->filesManager->getFile('some_image.jpg')
3. You get NULL as a result

Setup/Environment

• ProcessWire version: 3.0.35
• (Optional) PHP version: 5.6.25
• (Optional) MySQL version: 5.6.28

Repost of ryancramerdesign/ProcessWire#958.

Descriptions of core modules shouldn’t mention specific WYSIWYG editors (if it isn’t necessary). One core module states "like TinyMCE" in its description in a fresh 3.0.35 installation. The description should be more generic.

Short description of the issue

As per the title

Expected behavior

I would expect that unpublished repeater items would also have StatusOn(1) and therefore be 2049.

Actual behavior

They end up with 2048

Optional: Suggestion for a possible fix

Not sure if this needs a fix because I don't really know if it's intended or not. It seems inconsistent to me, but I am guessing there is a valid reason, so maybe this is more of a question that an issue, but I am not sure.

Short description of the issue

When specifying multiple fields of an another page than that being rendered in the edit tag, it only appear the first field in the modal window.
the edit tag would have a a syntax like <div edit="1024.intro,1024.image,1024.events"> ... </div>

Expected behavior

It should appear all fields specified in the <edit> fields in the modal window.

Actual behavior

Only first field of the list is present in modal window and behave correctly.

Optional: Screenshots/Links that demonstrate the issue

Optional: Suggestion for a possible fix

None

Steps to reproduce the issue

1. Step 1 I have the following code
   <tr edit="1244.priority,1244.startdate,1244.enddate,1244.title,1244.Description,1244.context"> <td><?= $info->priority ?></td> <td><?= $info->title ?></td> <td><?= $info->context->title ?></td> <td><?= $info->startdate ?></td> <td><?= $info->enddate ?></td> </tr>
2. Step 2 double click the row in the table
3. Step 3 the frontend editing modal window appears with only the field 'priority'

Setup/Environment

Local Apache server 2.4.17

• ProcessWire version: 3.0.35
• (Optional) PHP version: 7.0.3
• (Optional) MySQL version: 5.7
• (Optional) Any 3rd party modules that are installed and could be related to the issue:

Short description of the issue

A page's breadcrumb does not open the page tree at the parents parent position in some cases. This happens if the page to edit has not been called from the tree (this is the case if the edit link has been called from a custom admin page, for instance).

Expected behavior

In ProcessWire 2.7.2, a click on a parent item in a page's breadcrumb (see attached screenshot - "Level 3" for instance) opened the page tree at the position of this parent (link generated contains "?open=123" at the end).

In ProcessWire 3.0.8 and newer this function was changed: now a click on the last parent does not open the tree anymore as it was before. I believe the change came in with commit d57c9ef6186ec24144ce488842bb32c25aeb0cd2 (line 1262)
$url = "../?open=$p->id"; if($cnt == $numParents-1) $url = "../";

Steps to reproduce the issue

1. Open page tree in admin: http://domain.com/admin/page/
2. Open a page for editing, preferable some page deeper in a nested structure (third level or so). Copy the edit link to clipboard from address bar like this: http://domain.com/admin/page/edit/?id=12345
3. Go back to admin, CLOSE the page tree.
   http://domain.com/admin/page/
4. Paste back the page edit url from clipboard to address bar and reload page: http://domain.com/admin/page/edit/?id=12345
5. Click on the last parent in the page's breadcrumb (see screenshot above: "Level 3" in this case)
6. Result: page tree does not open at the position of the page in the tree.

Setup/Environment

• ProcessWire version: 3.0.36

Short description of the issue

I have encountered a problem that randomly after a deploy some modules are not available. It happens randomly, and to different modules. Clearing the FileCompiler Cache does not help in this case, after a redeployment the error is gone most of the time.
The module from the screenshot is inheriting the FieldtypeFile module and is adding some additional meta fields to the file and is hooking on file save and uploads the file to amazon s3.
The bug only occurs when PW is trying to access, when i ssh to the instance i can see and open the files.
The module has the namespace ProcessWire.

Expected behavior

Find all modules after deployment

Actual behavior

Sometimes a module is not found after deployment

Optional: Screenshots/Links that demonstrate the issue

Steps to reproduce the issue

1. Deploy application to an AWS Elastic Beanstalk application (i dont know if thats relevant for this bug to happen, but thats what we use for hosting)
2. Bug happens randomly

Setup/Environment

• ProcessWire version: 3.0.35
• PHP version: PHP 5.6
• MySQL version: MySQL 5.6.23

Briefly describe the issue.

When an internal server error occurs, emails that were getting triggered in PW 2.6 are no longer generated.

What did you expect to happen?

Receive email on error, sent to $config->adminEmail

What did actually happen?

No email is generated

Optional: Have you a suggestion for a possible fix?

WireShutdown.php sends the email if function_exists("wireMail"). I think that needs to be changed to function_exists("\ProcessWire\wireMail").

What are the steps to reproduce the issue?

1. Make sure $config->adminEmail is set, and server/dev environment supports wireMail
2. Break some code to generate a WireException. Hit broken code with browser. You should see the message "Unable to complete this request due to an error. - Error has been logged. Administrator has been notified."
3. Veiw inbox, outgoing maillog.

Tell us about the setup you experienced the bug in.

Linux, PW 3.0.34, PHP 5.6.x
$config->templateCompile = false;
$config->moduleCompile = false;

When having LanguageSupport installed plus the LanguagePageNames module, there's page name field also on "home" page. When editing one of the page name field and hitting enter, the image modal opens.

• ProcessWire version: 3.0.33

Short description of the issue

A locked pagefield seems to still load all possible pages in the PageEditor, even though only the selected one should be displayed.

Expected behavior

Show the selected page without issue.

Actual behavior

I've an installation with ~9000 users, which started to time out on editing any registration page. Hiding the page field, where the corresponding user is selected, from the editing form resolved the issue, while "Open when populated, …, Locked" as visibility did initiate the timeout.

Steps to reproduce the issue

1. Have a page field with a large number of selectable pages.
2. Add it to a template and set the visibility to "Open when populated, Closed when empty, Locked"
3. Try to edit a page of that template.

Setup/Environment

• ProcessWire version: 3.0.30
• (Optional) PHP version: 7

Short description of the issue

The breadcrumb link for the parent page of the current page does not link to the proper page.

In the following breadcrumb example, the "Parent Page" does not link directly to that page; it instead links to /processwire/page/

Pages > Home > [Parent Page] > [Current Page]

In the following example, the "Grandparent Page" link is correct, but the "Parent Page" link is incorrect:

Pages > Home > [Grandparent Page] > [Parent Page] > [Current Page]

Expected behavior

The "Parent Page" in the above example should link to the parent page of the current page.

Actual behavior

The "Parent Page" in the above example instead links to /processwire/page/

Steps to reproduce the issue

This occurs when editing any page in the admin. The incorrect link is always the immediate parent page of the current page.

Setup/Environment

Issue is not due to setup/environment.

• ProcessWire version: 3.0.33 devns

Only discovered this by chance: Ctrl+clicking (Command+clicking on Mac?) on Pages breadcrumb links does non-standard behaviour.

In Chrome: Ctrl+click does not navigate to the page tree as per normal click, but instead opens the clicked page for editing. That's unexpected, but would be fine if it were not for...

In Firefox: Ctrl+click does not open the clicked page for editing as per Chrome, but opens the adjacent page for editing. So for breadcrumb: Home > Foo > Bar > Baz, clicking Home opens Foo, clicking Foo opens Bar, and clicking Bar opens no page for editing but instead navigates to the page tree.

And in IE11, Ctrl+click is just the same as a normal click - no page editing possible from breadcrumb.

If this Ctrl+click behaviour is a feature not a bug then it should be consistent across modern browsers.

• ProcessWire version: 3.0.36

Short description of the issue

When adding a new user, the password box tells me the password is too common, even though it satisfies all of the requirements, but only if it has a ^ character in it.

Expected behavior

When I type in S7z^w5Fr as the password, I expect it to tell me it is 'OK'.

Actual behavior

It tells me it is "Too common"

Steps to reproduce the issue

1. Create a new user
2. Enter S7z^w5Fr as the password
3. Notice it says "too common"
4. Now substitute the ^ for an asterisk or something, and suddenly the password is 'OK'

Setup/Environment

• ProcessWire version: 3.0.35

Short description of the issue

MySQL error when ordering users by role in users admin page table

Expected behavior

Rows order by role (thinking of it, there are many roles, so it's not that easy. Still, we shouldn't get an error)

Actual behavior

I get this error:

SQLSTATE[42000]: Syntax error or access violation: 1055 Expression #1 of ORDER BY clause is not in GROUP BY clause and contains nonaggregated column '{removed}._sort_page_roles_name.name' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

Steps to reproduce the issue

1. Go to Access > Users
2. Click the title of the "Roles" column
3. The page will be messed up, even if you leave and return again. Logout and login to get it back.

Setup/Environment

ProcessWire 3.0.35
PHP: 7.0.11
Apache: 2.4.18 (Unix) OpenSSL/1.0.2g
MySQL: 5.7.15-0ubuntu0.16.04.1-log

I have page "Products" with a lot of urlSegments:
site.dev/products/pigs/antibiotics-injectable/antibiotics-external/antibiotics-oral-solutions/antiseptics-external/vaccines-live/feed-additives/disinfectants-and-hygiene/

In config
$config->maxUrlSegments = 12;

Everything works great until I switch on cache for this page.
After that I get:
file_put_contents(D:/Server/domains/localhost/site.dev/app/site/assets/cache/Page/3725/pigs+antibiotics-injectable+antibiotics-external+antibiotics-oral-solutions+antiseptics-external+vaccines-live+feed-additives+disinfectants-and-hygiene+4c81f131016c84203e1525aef538e4ed.cache): failed to open stream: Invalid argument

ProcessWire version: 3.0.33
PHP version: 5.6
MySQL version: 5.5

There is FieldtypeFleat field "my_float_field". I have few (strange) issues with it - I think they are connected, so posting both here.

Issue with storing/getting

When I want to store null in this field, it doesn't save (or return) null. I want to get null back when I save null and 0 when I save integer 0. What's wrong here?

$value = null;
echo 'Type=' . gettype($value) . ' Value=' . print_r($value, true));
$page->setAndSave('my_float_field', $value);
echo 'Type=' . gettype($page->my_float_field) . ' Value=' . print_r($page->my_float_field, true));
echo 'Type=' . gettype($page->my_float_field) . ' Value=' . print_r($page->getUnformatted('my_float_field'), true));

// Result:
Type=NULL Value =
Type=double Value = 0
Type=double Value = 0

Issue with visibility

This field has Visibility=Open+Closed when blank+Locked
If I save null in this field, it disappears from page edit admin. If there is some value - it shows it normally... If I change setting "Blank and 0 have different meanings" to "... equivalent" it also does not help. This looks like either bug or some db issue. I've checked field settings in db and didn't find any strange things there... so tend to think that it is bug.

Request to support is here https://processwire.com/talk/topic/14355-few-strange-issues-with-storinggetting-null-in-float-field/#comment-129154 but answers do not fix issues.

• ProcessWire version: 2.7.2
• (Optional) PHP version: 7.0.11
• (Optional) MySQL version: 5.7 (ALL TABLES ARE INNODB)

Short description of the issue

I'm not able to upload certain gif files(*). Default images field, valid file extensions: gif jpg jpeg png.

(*) This behaviour doesn't occur for every gif file.

Expected behavior

The gif gets successfully uploaded ;)

Actual behavior

JavaScript enabled:

The gif won't be uploaded (the loading icon never stops spinning).
The following error message occurs:

VM1720:1 Uncaught SyntaxError: Unexpected token < in JSON at position 0
    at JSON.parse (<anonymous>)
    at Function.parseJSON (JqueryCore.js?v=1475855324:2)
    at XMLHttpRequest.<anonymous> (InputfieldImage.js?v=119-1475855324:1403)

InputfieldImage.js: var response = $.parseJSON(xhr.responseText),

JavaScript disabled

The gif gets uploaded but the following PHP Notices occurs:

Notice: Undefined property: ProcessWire\PWGIFIMAGE::$m_nDelay in /../public/wire/core/ImageInspector.php on line 231

Notice: Undefined property: ProcessWire\PWGIFIMAGE::$m_bTrans in /../public/wire/core/ImageInspector.php on line 232

Notice: Undefined property: ProcessWire\PWGIFIMAGE::$m_nTrans in /../public/wire/core/ImageInspector.php on line 233

Screenshots/Links that demonstrate the issue

This is the gif file I'm trying to upload.

Suggestion for a possible fix

@ ImageInspector.php:231 @ class ImageInspector extends WireData {
-    $i['delay']     = $gi->m_nDelay;
-    $i['trans']     = $gi->m_bTrans;
-    $i['transcolor']  = $gi->m_nTrans;
+    $i['delay']     = isset($gi->m_nDelay) ? $gi->m_nDelay : '';
+    $i['trans']     = isset($gi->m_bTrans) ? $gi->m_bTrans : '';
+    $i['transcolor']  = isset($gi->m_nTrans) ? $gi->m_nTrans : '';

Steps to reproduce the issue

1. Try to upload the gif file linked above.

Setup/Environment

• ProcessWire version: 3.0.36
• PHP version: PHP 7.0.5

Short description of the issue

The lineToEntry() method used by the log viewer (Setup > Logs) can only parse files with a tab as the delimiter (https://github.com/processwire/processwire/blob/bac5b0de5d95b5a10c09f48ba5e63b419ee68799/wire/core/WireLog.php#L301), but the WireLog::save method supports custom delimiters (https://github.com/processwire/processwire/blob/bac5b0de5d95b5a10c09f48ba5e63b419ee68799/wire/core/WireLog.php#L105).

Expected behavior

Not sure :)

Actual behavior

A log file using another delimiter wouldn't be parsed correctly.

Optional: Suggestion for a possible fix

Maybe the simplest / only option is to remove the delimiter option when saving to a custom log file, but I am really not sure.

Short description of the issue

When selecting a module zip to upload it no longer shows the file that has been selected. I think this change happened maybe when the upload button was styled - I think that was fairly recently.

Expected behavior

You should see the name of the file that was selected.

Actual behavior

The button is "grayed out", but that's the only indication you have that a file was selected.

Optional: Screenshots/Links that demonstrate the issue

Briefly describe the issue.

Repost of ryancramerdesign/ProcessWire#1132

What did you expect to happen?

Long words to break at the line end.

What did actually happen?

Line does overflow.

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

https://www.dropbox.com/s/xhdnkdum8ozaric/Screenshot%202016-10-01%2010.58.24.png?dl=0

Optional: Have you a suggestion for a possible fix?

word-wrap: break-word;

What are the steps to reproduce the issue?

Put a long url in the field description or notes.

Tell us about the setup you experienced the bug in.

• ProcessWire version: 3.0.35