Recently Browsing 0 members
No registered users viewing this page.
I could have sworn I used to be able to use the site generic 'title' field as a sub field of a repeater field. However I've tried to do this on two 3.0.165 sites recently and, while it will add the title field in the repeater field setup, it wont save the repeater title sub field's content when the repeater is used in a page template and edited.
It;'s not a big issue but I wondered if this was a known restriction?
By Guy Incognito
I seem to be running into a repeated fatal error in a fresh PW install version 3.0.148. I can't quite put my finger on the pattern but it seems to be around deleting image fields or removing images from certain image fields.
This is the trace from the log generated by trying to save a page and delete an image from an image field:
Fatal Error: Uncaught Error: Cannot access protected property Pageimage::$original in /wire/core/PageimageVariations.php:256 Stack trace: 1. /wire/core/Pageimage.php(1327): PageimageVariations->getInfo() 2. /wire/core/Wire.php(386): Pageimage->___isVariation() 3. /wire/core/WireHooks.php(823): Wire->_callMethod() 4. /wire/core/Wire.php(450): WireHooks->runHooks() 5. /wire/core/Pageimage.php(1369): Wire->__call() 6. /wire/core/Pageimage.php(399): Pageimage->getOriginal() 7. /wire/core/WireData.php(333): Pageimage->get() 8. /wire/core/PageimageVariations.php(256): Pro Line 256 of /wire/core/PageimageVariations.php Earlier in the day I was experimenting with custom fields for images for the first time and kept running into this error, thinking it was me using this feature wrong and not having time to read up I deleted the custom image fields template and went about my business. So now I don't know if I triggered an issue or whether it was never related to the custom image fields in the first place?
Since I'm doing a lot of detailed logging in our internal PW-based systems, that has become a bit of a bottleneck under heavy load and I was missing a centralized view with the growing number of separate PW instances. So I dug into the core a bit, namely WireLog.php and FileLog.php as well as ProcessWire.php. I managed to whip up my own WireLogDatabase and DbLog classes mimicking the behaviour of the regular logging classes, but not without a little bit of tweaking to the ProcessWire class itself to replace the regular logger. Now I'm logging to a MySQL server instead of plain files and ProcessLogger works smoothly with it without tweaking.
I thought it would be shame to keep this all to myself, but a release-worthy version would need or could benefit from:
a bit of polishing in regards to error handling and proper treatment of conflicting concurrent operations without too much lock overhead (drop table vs. insert especially) more source code documentation a little more abstraction so all csv operations are deprecated in favor of database columns where avaible last but not least, an approved way to configure the substitute logger and load it early on, which means touching the core ProcessWire class Before I invest too much into that, I'd love to hear all thoughts on this, especially if you think such a module may fit your requirements, and I would be especially happy to hear from @ryan - could you see such a mechanism in the core?
I am starting to use ProcessWire.
So, i need to extend the ProcessTemplate Module. I need to add a required field to the templates into the Advanced Tab (for personal purposes)
I already added the field, but inside the core folder, but this is a very bad practice.
The best would be add the modifications inside the site folder.
How could i extend the core module ProcessTemplate in order to not affect the core, and the processwire read my extended modifications.
Thank you very much everyone.
What are your experiences with profile/color consistency when using Image Magick for resizing?
I know @horst is probably the person with the most experience on this, (hope you can chime in here Horst)
I noticed that In some cases Image Magic resized jpgs appear darker than the original, and after some digging it appears to involve various factors concering both the image preparation (Photoshop's save for web and even general profile handling before that) and the way the Image Magic resizing process is setup.
- Images with an embedded (srgb) profile that were exported via Photoshop's "save for web" function with "convert to srgb" and "embed profile" ON, somehow result in muted colors and a darker image, (actually it looks very much like when you would assign an srgb profile to an image that was already converted to srgb before, not dramatic, but quite noticeable with e.g. reds and cyans.)
- I tried multiple variations, with embedded and excluded srgb profile, "convert to srgb" on and off, but the result appears to be the same darker, muted image. Need to find time to do more structured testing though..
- The way the srgb profile is embedded in the jpg
- The way the Imagick module detects/ignores profiles
- Colorspace handling changes between imagick versions
- One of the above plus these rather involved technical reccomendations (tldr: convert to linear RGB, resize, convert back)
Would be nice to get a discussion going here. I am out of my league with this, technical knowledge wise but I'll try to keep up