Jugibur

So great updates, many thanks for this work! A little cosmetic thing: The size of portrait images In list mode are very large and blurry even with the smallest possible slider setting. Could be confusing for customers. Maybe limiting the longest side of an (portrait) image to a maximum to render it smaller but sharper? Besides that the proportions / sizes of portrait and landscape images are more homogenous to each other. EDIT: Oh, 2 minutes after sending this I found the checkbox "There are older/low quality thumbnail preview images above – check this box to re-create them." So the blurring is gone... sorry. Only the size for portrait images seem too big (for my eyes) – especially if you shrink the viewport – after the break they take a lot of space.

Looks very well plus great functionally additions – thanks to all involved people for your work! PS: What are you think about renaming an file in the backend (i.e. for SEO adaptions)? This is the only thing I've sometimes missed.

Compared to other CMS I found the resources quite good – but I must admit, my knowledge about PW only scratches the surface ;-) So thanks for these updates and the effort!

Ok, now it's clear, thanks for your explanations!

Yes, sRGB is the standard for the web and the most devices are able to show this more or less in the same way. My question above about preserving an icc-profile after resizing (perhaps for a thumbnail) was because even if you have sRGB converted images, but they are tagged with an sRGB-profile, they are different rendered on wide-gammut monitors on nearly all browsers (tested on OS X). Without an sRGB-profile embedded they shown more saturated / luminous on wide-gammut monitors. Yes, the graphic designer / photographer should do the right things in his editing app before embedding it to a website, but that's another topic. Lets imagine / assume an editor haven't the possibilities or the knowledge to correct his images in the "right" way... So even stripping an sRGB profile from a sRGB converted image have effects. That's why I'm asked for the possibility to let the admin choose if the profile should preserved (or more general, if it is possible *without* Little CMS anyway).

Thanks for clarification, Horst! But unfortunately, stripping all markers (and icc-profiles) arent't always help to make a homogenuous rendering, because Browsers interpret images without profiles in different ways. Try this test with Chrome, Firefox and, if you have, Safari: http://cameratico.com/tools/web-browser-color-management-test/ Especially the section "How does your browser interpret untagged images and page elements?" is expressive: It shows, that Chrome and Firefox interprets untagged images in a wrong way (to what the W3C recommends). The colors are unnatural luminous compared to Safari (in OS X). So if converting a profile isn't possible in practice why not let the admin choose, if he wants to preserve a icc-profile (like Adobe RGB)? But is it possible just to preserve the icc-profile after resizing the image? I have found different answers and infos and since I know from your post there are different builds / versions and sometimes the need of Little CMS, what's your opinion / infos here?

Thanks Ryan and Horst for this great improvement! Newer ImageMagick versions preserves the color profiles as I know. Perhaps this is causing some of the file size difference in the examples. If explicit no profiles wanted, they could be removed with the "-strip" parameter. If you have AdobeRGB profiles embedded, image colors could be flat on sRGB-Monitors and/or some Browsers without color management. With IM you could convert these profiles to sRGB.

They (EU) say, that websites with necessary cookies (like for shops or some kind of forms, etc.) don't need to show this hint-panel to users. You need it only, if you kinds of user tracking or advertising across a network. Additionally, Google 2015 have made the oblication to show this cookie-hint to users, if they use AdSense. See: https://support.google.com/adsense/answer/6245892?hl=en

Thanks for your work, Can, works fine! Would mention, that we (fortunately) don't need to show this info-panel for data which is relevant for the website (if I read the EU law correctly). Otherwise, it would be very annoying to see these info-panels on every 2nd website ;-)

Sorry for late reply... I have now set my profile for perpetual notifications if a thread has new posts I've made a second language and added it to the profile. For testing I have re-installed the language module, but still doesn't work. I remember the de-language was missing suddenly, not after the update. Will try a fresh installation for testing purposes... EDIT: I've no done a fresh installation of PW 3 with the language files and now it worked!

Is it for developing / internal use cases? Recently I found a module by user Adrian, called Tracy-Debugger: It shows you the processing time and *a lot* of other infos in a nice way, including PHP error reporting. If you don't know it, here's the thread: https://processwire.com/talk/topic/12208-tracy-debugger/

I'm curious every week, what surprises you will pull out of the hat – feeling ProcessWire is a "living" thing, growing and growing... ProDrafts looks so great, especially the side-by-side preview – so let's do a purchase... EDIT: +1 for adding support for Repeater / Repeater Matrix in one of the next versions...

Has someone used this in combination with PW 3.0.8? I've installed it (like in PW 2), set the installed language in my profile, logged out / in, deleted the cache – but no translation anywhere :-/

Yes, you're right with my additionally edit, I've removed it meanwhile. Thanks for the explanation about the page fieldtype, I didn't know that. I'm just wondering that no one needed and created such a type before, Is my scenario 2 so far from a practical use case?

Hi together, I'm wondering, why there isn't a fieldtype for grouping other fieldtypes together. Have bought die ProFields and looked in the external Modules section but found nothing in this kind. And as I read in this thread it seems not possible: https://processwire.com/talk/topic/4590-something-like-repeater-field-with-only-one-entry-allowed/?hl=group Yes, there is the fieldset for the a template, but I mean a real fieldtype. For what? Here my scenario: I want using the Repeater Matrix for adding some content and render this inside a CSS grid. To set up the grid / rows / columns with a width (span), the offset and other things it would be great if I could define a set of the needed input elements inside a field(type) for re-use. In this case, you don't need to add this input elements for each content inside the matrix but you could choose just this set because it is a pre-build field. The bonus is, you still have the layout for the fields ready made in this field. Imagine like the "Table" field but without repeating the elements or like the "Textarea" field with different fieldtypes. Another scenario could be: You have different page template (of course) but in each (or most) of them you want to have the same set of input elements, say for SEO, some Meta-Data or for defining a header slider or another element. If this is possible I'm thankfull for any hint, if not, what do you think about this type of field? Juergen