tpr

This is the "Sticky CKE toolbar" feature located in the RenoTweaks. I'm also using it and most of the ime it works fine but sometimes there's a jump when the toolbar goes to fixed position and its height is changing. There's a "Fixed" CKEditor plugin that never worked well for me (even with the fix in their forums) so I revisited this again today and found a nice and easy solution using position:sticky. This works in latest browsers only but I think it's still better than the current one - no hacky JS/CSS, and works with multiple editors too. I'll upload this new version soon, until that you can uncheck this feature.

Yes, I grabbed the parent div of the articles div that contained the prev-next links too. This way the Load more button could trigger the right Next link. I can share the jQuery snippet though it's WP-specific and currently has no history feature. Plus the Load more needs manual click so you'd have to implement a check on scroll if you need it to automatically load next posts.

Is the issue present only with repeaters?

Thanks, these filenames are OK at first sight, but it's the JS workaround that is failing (so it's not horst :)). I wasn't able to entirely duplicate the issue but if I uploaded an image and set a crop without saving the page itself first, there was a JS error that prevented the preview to update (uninitialized tooltip). I've fixed it here, so please try updating this file: https://github.com/rolandtoth/CroppableImage3/blob/master/InputfieldCroppableImage3/InputfieldCroppableImage3.js If this doesn't help, you could hide the preview image until a better fix (eg. with some admin CSS).

You mean the button preview hover image is not updating or the icon-size one on the crop button? If the latter, is there a js error? Could you share the preview img filename?

Recently when I added a similar feature I grabbed the div containing the Next link too from the next page, so I got always the updated link (I used no plugins).

I just use this syntax: $page->images->first()->getCrop('portrait'); I guess horst needs to fix the removal for the other syntax as well.

@PWaddict My variations looks like imagename.-work-thumb.160x135.jpg, where 160x135 is added by me from api (markupsrcset module). It seems you have a different naming somehow. @horst You got a new PR - button preview update on new crop + prevent PW lightbox on preview img click (lightbox showed 'Error load image') + style updates Feel free to remove the new preview button styles if you don't like it.

Thanks @horst, just checked and I can verify it works as expected! A few things (nothing biggie): the original image seems to get a new modified date in the filesystem. Is it necessary or a bug? I would love to see a tiny preview of the cropped image (without hover). Would it be possible to append eg. a 0x48px (or so) thumbnail image to the crop size name? Just to have a small indication how it looks like. Tracy shows a PHP notice in the main module's settings page: "PHP Notice: Undefined index: sharpening in .../FieldtypeCroppableImage3ConfAdaptor.php:96" Anyway I'm happy this issue is fixed, now I can continue uploading images to a site that I put aside. Thanks again!

I don't see how this could be tweaked by aos easily, I would wait for the image handling updates that are on the roadmap instead. https://processwire.com/about/roadmap/

Just updated the module to version 0.1. Almost everything in it has changed so reading the docs is a must The module does less "magic" as before, eg. doesn't add the "lazyload" class and data-sizes automatically. These should be added manually or you can write a wrapper function if you would like to simplify things (please notify me if you think you wrote one that should be part of the module). Also all the module settings are gone except the "Load scripts" checkbox because all other settings became useless after the rewrite. The new syntax looks like this (here with a helper to add a noscript tag for no-js fallback): <?php $img = $page->featured_image; ?> <img data-srcset="<?php echo $img->srcset('200x300,*2,*3'); ?>" class="lazyload" data-sizes="auto" alt="" /> <noscript> <img src="<?php echo $img->srcsetUrls[0]; ?>" /> </noscript> The main change is that you can easily tell what image sizes (sets) you need ("200x300,*2,*3" in the above example). Of course you can use WxH values for each set or use divisors too. What's more you don't have to start with the lowest image size, eg. "1200x900, /2, /4" is perfectly fine.

Or you can use the original Autosize Textareas module (sorry I didn't remember :)).

You can disable all other submodules within AdminOnSteroids and enable only the Autosize tweak at the Misc submodule. If it's still too much you'll have to add your custom JavaScript to the admin (along with AutoSize js) and apply on document.ready().

https://github.com/rolandtoth/AdminOnSteroids/wiki#misc

Thanks, that's coming from the latest PR I merged yesterday, will fix soon.

Thanks @adrian, I haven't came across these issues, good to know. The AddNewChildFirst submodule works pretty neat, thanks for your contributions in this topic - I only collected all the goodies from there

Indeed, thanks! Time to revisit https://vivaldi.com/blog/snapshots/docked-developer-tools/

I haven't switched to it because devtools can't be opened attached, only in a separate window. Have they changed it lately? I'm happy with Slimjet, it's also Chromium based but allows many useful additional features, and available as a portable version too (for Win).

Thanks! It's the most moving story in this topic

I've updated the pens, now it is possible to add padding and show text too (left or right side).

AOS: AdminOnSteroids module

This could be part of AOS, perhaps with an option what templates to include.

Awesome, thanks!

I think it's a different thing what @dreerr is talking about. Consider this scenario: Set a crop setting on an Image field, eg. "work-thumb, 320, 270" Use it with a srcset solution (either with a module or manually) and that will make you a 320x270 image and some variations - let's assume only one, 160x135: image.-work-thumb.jpg image.-work-thumb.160x135.jpg Now edit the image again and crop a different part. The results: image.-work-thumb.jpg <- changes according to the new crop image.-work-thumb.160x135.jpg <- no change! I'm also interested in a solution because CI3 can't be used for srcset purposes atm if I get it right. What I could imagine as a simple fix is that when CI3 saves a new crop it would delete any size variation of it (in this example all images that are named "image.-work-thumb.WIDTHxHEIGHT.jpg"). Then the srcset generators could re-create these size variations again. Perhaps this behavior could be optionally set in the module's settings.

That's why I wrote "get" instead find. On a page save hook you could save the field so no additional page save would be triggered. http://cheatsheet.processwire.com/page/built-in-methods-reference/page-save-field/