ottogal

I crowed too soon: After a new start of the backend I made a modules refresh to find the following "success" message (green): And the installed version is again 0.1.4 ... (By the way: In the case of multiple files for a module, one with the trailing "-master" and one without it, which one should I use? What's the difference?)

My other modules all are up-to-date, so I can't say. Thank you for the idea! Uninstalling and reinstalling the module solved the issue. (Before the reinstall I had to delete the files in the modules folder.) Many thank, adrian!

Hhm, getModuleInfo() returns 'version' => 15, and all the files have the date of yesterday (my update). Obviously the update process was successful. But the entry on Modules > Site continues to display 0.1.4, the settings page is the old one. The new functionality is not available... Should I try to uninstall and reinstall the module, instead of updating?

Did both, same result: If I click "Continue to module settings" (below the "updated successfully" message), the settings show the 0.1.4 version.

Hi all! Bringing up this old thread... My hope was to solve this by modifying the entries in the textarea "Table fields to display in admin". For, say, a field "text" of fieldtype file with the Label "Notes" I had the entry "text.filesizeStr", hence the column title was "NOTES > TEXT.FILESIZESTR". Wanting the title "SIZE" instead, I tried the entry "Size=text.filesizeStr". And really, the column title changed to "SIZE". But the column lost its values - all its cells were empty. So I assume that it needs just a slightly different syntax for the entry to work... Suggestions welcome!

Hi @adrian, sorry for the late reply. I tried to install the new version 0.1.5 from the Backend via Modules > Site. Despite the notification of the successful installation, the module was not upgraded. (I'm running PW 3.0.15).

I also tried upload_max_filesize 200M and post_max_size 300M , to no avail (neither via .htaccess nor via config.php). It seems that the file size is not the culprit - it doesn't work even for very small files. In /wire/config.php I found the Bad file extensions for uploads, but mp4 was not amongst them. Then I saw the section and added the line 'mp4' => 'video/mp4', but without success. BTW: Uploading the mp4 files via FTP and refering them in the HTML code works without any issues. I really need help what to do... Thank you

Same for PW 3.0.15 Are there any news on that? Thanks.

PHP Version is 5.3.28-nmm5 upload_max_filesize is 200M (both values) post_max_size is 200M (both values) So this should not cause the problem...

As far as I see I don't have access to the php.ini file (hoster is all-inkl.com). Can I change these values via .htaccess?

Hi all, I encounter a strange issue. I have a field of type File with just mp4 as allowed file extension. A page is using a template that has this field added. Editing this page, I start the upload of a local mp4 file (around 90 MB of size) to said field. The progress bar is proceding until 100%, but then the download hangs; the wheel symbol doesn't stop rotating. What might cause this behaviour? (PW 3.0.15)

I think that should be $content.= $map->render($items, 'contact_gps'); (without " ")

Could it be just a typo? (closing quote missing)

Hi all, the module version 0.2.1 claims compatibility with PW 2.5, 2.6, 2.7 - but not 3.0. I tried to use it in PW 3.0.10 devns, and it works like expected as long as I leave the setting saveMessages unticked. Checking this option throws the following message: Line 747 of that file is $spamMailsMsgs = $receivedMessages->find('scf_spamMail!='); Most likely it's some other problem and not the PW version causing this error. But for compatibility, would it help to replace the <?php by <?php namespace ProcessWire; in all the php files of the module, or is there more to do to get it compatible?

I have to overwrite the default Prohibited Message in each individual page Setting. I'm missing the possibility to do it in the module's Settings for all ptotected pages.

I understand. But then the hint under Instructions ("... or use the "Protect Entire Site" shortcut below") should be removed in this case, too.

On the Settings page of the module PageProtector 0.1.4 the "Protect Entire Site" shortcut is missing. Was it removed intentionally?

@adrian: Thank you for your time, anyway. At the moment I don't have the time to dig deeper into it, but surely will try later.

Thank you, adrian. Yes, I'm using the PageProtector module (forgot to mention it). Members get only page view, not page edit permission. They should not have access to the backend.* Members have the roles "members" and "guest" - you can't remove the guest role from a user. They don't have any of the roles with page edit permission. *Edit: This doesn't work - they have access to the pages tree (not wanted), but see just the view buttons.

I read all over the docs and the forum about protecting certain pages from access and wonder why my efforts are unsuccessful. The situation (simplified): Pages tree Home - Free Stuff - - Free1 - - Free2 - Private Stuff - - Private1 - - Private2 Free Stuff and its children have the template "standard"; Access managing is set to No. Private Stuff and its children have the template "private": in its Access settings the page view option is unticked for the guest role. Apart from superuser and guest there are the following roles: editor member The editor role grants page edit permission for all the pages. Users having the member role have to log in to get acces to the private pages. Now my question: What do I have to do to give the member users page view access exclusively for the private pages? (That is, they should not see the pages of template standard.) What I tried: In the Settings of the page Free Stuff I ticked Protect this page, then Protect children too. As Allowed roles I selected all but the role member. So I expected that a member user would no longer have access to the Full Stuff page nor its children. But that doesn't work. Maybe I'm missing something obvious. Any help is hihgly appreciated!

If I understand it right, using the options 'outer_tpl' => '<ul class="uk-nav uk-nav-parent-icon" data-uk-nav>||</ul>', 'inner_tpl' => '<ul class="uk-nav-sub">||</ul>', 'parent_class' => 'uk-parent', should do it.

Stumbled over this old thread... These are different: 1 kB = 1000 B vs. 1KB = 1024 B https://en.wikipedia.org/wiki/Kilobyte (In former times, some producers of harddisks, even if they indicated the capacity in KB, they meant kB - so it looked bigger...)

No, I haven't installed any other image related modules.

Applying your modified function on my test image I got this output: Searching the web for information on the Exif tag Orientation you find dozens of sites and forum posts which show the subject is really a complex one, given that various hardware and software is treating it differently. So asking for the camera model was not as far-fetched as it seemed... Here's one link I found quite instructive: http://www.impulseadventure.com/photo/exif-orientation.html Edit: Two more links: http://www.daveperrett.com/articles/2012/07/28/exif-orientation-handling-is-a-ghetto/ http://keyj.emphy.de/exif-orientation-rant/

@horst: Strange things are going on. As you proposed I set autoRotation to false in both the config settings imageSizerOptions and adminThumbOptions, and put your image call in a template, used by a newly created test page. Result: Already with the upload of the test-image to the images field of the test page the created thumbnail was autorotated (i.e. displayed upright). Viewing the page, the half-sized image is oriented correctly, too. Inserting the original, full sized image into the body field (textarea/CKEditor) resulted in an autorotated output (backend and frontend). In the folder /site/assets/8765/ (where 8765 is the id of the test page) there is the file image test_1.jpg (width 600), not rotated like the original, and the half-sized image test_1.300x0.jpg, rotated to the correct orientation. (*) To crosscheck I reset the autoRotation settings in the config both back to true. Now both the admin-thumbnail in the backend and the half-sized image in the frontend are displayed not rotated (the latter one, inserted by the template, of course doesn't show in the frontend). But the full sized image inserted via the CKEditor ist autorotated correctly, both in backend and frontend... Thanks a lot, Horst, for your help! (*) Another strangeness: The original file I uploaded was test_1_.jpg, i.e. the name had a trailing underscore. This obviously is removed by PW processing the image. (But I don't think that has any influence on the problem in discussion.) EDIT: I also called your function checkOrientation(), it returned nothing.