ceberlin

Hi Horst, thank you for your quick replies (I know you are busy)! If I can say thank you with a little invitation, send me a pm. That said, I was really inadvertently resetting all crops (many, many) on my test site. But I had a backup in place, I know I run on thin ice with early beta software but I am so extremely happy that the cropping is working again. I was expecting that - as you wrote earlier here - it does not matter if the cropped versions are deleted, they would be recreated with the stored cropping coordinates. But in fact they were all reset to default instead. Maybe that had to do with the fact I was updating the module only and had no fresh setup. After the page is saved once, the positions get remembered most of the time, but still not always. - If I have more information, I will file a report at your GitHub page.

A compatibility warning: After testing this with the new Croppable module (which is currently in beta and works with PW3 beta): https://processwire.com/talk/topic/8709-croppableimage/page-7#entry119754 Right now this SpringCleaning module treats crops as "variations" and resets then too! - This is not desired in most cases!

By the way, for anyone interested: For an aforementioned spring cleaning there is a little module existing already (credits to Horst and tpr): https://processwire.com/talk/topic/261-where-to-set-image-resizing-quality-and-how-to-re-resize-images/page-2 Update: A WARNING: Right now, that spring cleaning module treats crops as "variations" and resets them too - which normally is not desired.

Interesting. Did not know about forceNew although it's in the core for a year already. Thank you for the hint. Very useful for spring cleanings. To add an automated approach I could try to find all variants and see if any of their dates are older than the one of the master image. In each template where the image occurs. Is it this what you mean? I am just worried of the overhead and it makes the implementation of variants of cropped images in templates more complicated. Isn't it a much easier and newbie friendly approach to just have the module remove existing variants (if any) on saving if the crop, so PW simply can recreate them if and where needed? (If that helps: the old module version / PW2 worked flawlessly already with those recreations, no further action needed.)

Thanks a lot again, Horst. Looks like the update created no problem. During the process I run into an Exception after hitting "Update Modules". But clearing the compiler cache files another time and hitting "Update Modules" again, fixed it. I have something funny because I use the cropped image to resize it further with PW. Here's what I tried I change the crop and save the page I check with FTP that a new cropped version is saved that looks like I want it In my code I work with that image as source for further manipulation, like so: $img_medium = $child->keyvisual->getCrop('header_thumb')->width(767, array( 'upscaling' => false, 'cropping' => false, 'quality' => 70 ) ); Expected behavior: those get updated too. Current behavior: No change to the images (PW does not detect them as changes and to be redrawn) I delete those variants manually with FTP to force a redraw - PW redraws them correctly now Is this an issue to report for PW or is this something with the module so PW3 does not know about the change?

This is SOOO cool - thank you Horst!!!!!! If the module was previously installed (old version with PW2.x) - can I just continue using it (with PW3.x) or are special steps needed/recommended now to update to the beta? (My first impression was it works right away but I am still testing.)

Hi Teppo, is it possible to use Swift Mailer's S/MIME encryption capabilities somehow with this module?

Hi Horst, a quick question to the roadmap: is this module still maintained or do I need start looking for an alternative? In PW 3.x I have the problem that, if I change the crop later, it is reflected in the preview but the frontend image does not always update to the new cropped version. (If I am the only one having this it could be also a misconfiguration or rights problem?)

I solved it by doing it a little bit differently - now sorting and filtering works: $siblings = $page->siblings("sort=date"); $prev = $siblings->getNext($page); $next = $siblings->getPrev($page); "Last" and "first" can be tested easily: if you reach the last or first item, $next or §prev return NULL (or have no ID) - LostKobrakai's code works great to catch that. So the difference was that I build my own pageArray ($siblings) instead of using $page, as suggested, to enable sorting. It was so easy to solve that I did not see it right before my eyes

Do you have the demo without/or different music? The German GEMA and SME had YouTube blocking the video for Germany.

One more idea For testing and debugging malfunctioning redirects (redirects can come from so many sources, htaccess, PW core, modules) it would be great to being able to either deactivating the module temporarily (preferred) or to temporarily uninstall the module without loosing all the stored data.

Avoiding cross language linking are a big SEO topic. An option like the one you mentioned would be great. (And maybe that all is only needed if Languages are active (module installed, more than 1 language counted?) Or leaving it as it is and adding a language selector for the installed languages placed before the target link and shown for multilingual setups? - Just thinking loud. What the module has and what I like is a very good search for links substrings on the source and target side (think of cases of 500+ redirections). And a debug option where every redirect is logged and shown the same way as 404 errors, with listing source and target for each incident. In case of redirect problems (first of all: loops) those information can be extremely valuable. And it has an optional cache.

(3)The buttons are there: Do you want to have access to a website where you can see the plugin in action? It's pretty advanced. Maybe it is inspiring for your new project? I installed the beta from today: I set this and still got this after save: The string that I had set manually "en/helium-vola/" had been replaced again by the page-id and ignoring the language. If you touched that in the beta, the behavior is still unchanged...

Yes en is replaced with de on save (or maybe without any language path information and PW adds this later) That the module does not handle languages is a surprise because I thought it did - South Africa alone has so many languages ) OK, what I see: it keeps the paths at the source. If there is an /en/ in it stays there. The target is "treated" somehow. It appears that it shows the path always in the language I use as a user. If I change my user language, the target paths change. Not sure how the effects are if a bot comes. Probably always en or what I set as hreflang='x-default. Test buttons: The idea was to have a quick possibility to check if the redirect is still needed and still valid. I am used to this from a very good Wordpress plugin. (That plugin is a very clever beast, by the way: http://codecanyon.net/item/seo-redirection-pro/7596396 it even has a history for any redirects made - which is usefull to track errors, if you have many redirects - on of our sites has 500 redirects) I would not have a problem with wildcards are left out and the source button is inactive in that case.

Small ideas: I would love a lot if there was an "external-link" button before the Source string and the Target string. Clicking on it would send me to a new window with the page loaded (or not). So I can quickly test the Target (valid) and the Source (if the redirect applied is working). I would like a dupe check - So the same string is not entered twice. If I use the 404 monitor to fix a link the link should be removed from the 404 monitor so I do not fix it twice

Not sure how this works... If the source link has a language in it (en) then I want to redirect always to that language: en/label/carl/ --> en/label/management/ Jumplinks does some autocorrection after save, and because I as a user have my profile language set as de (German), I see this: en/label/carl/ --> de/label/management/ Did I set it up wrongly or is this something that goes wrong? (Google does not like cross-language linkings)

Interesting. The very trendy Google font "Merriweather" I use seems to be incomplete at Google (outdated?), it is missing the "fi" ligature and instead only shows an "i". Safari is now using ligatures. With this code I could tell Safari to stop using ligatures: -webkit-font-variant-ligatures: no-common-ligatures;

Nice, thank you If this is for your memories, this is not a bad thing. A lot of knowledge has just disappeared from the web. Not every band was organized enough to catch up with the internet early and left almost no traces. So they, and their audience (and me), have their platform back, finally. Since this is my Processwire 3 testing ground, I will probably do much more with it, if I have the time.

This is a website about a label I had in the past. After a long pause it was time to set the former label website up again (with a new look) by popular demand. The whole site was set up in less than 2 months in my spare time: setting up everything, creating templates and loading the data page by page. 2 languages (with a main emphasis on German) and everything's fully responsive. Thanks to Processwire and UIkit no problem. - Ryan, thank you for this wonderful CMS. This is only the beginning. If people are using it (and it looks like that) I will expand this thing with videos and more. https://www.chrom.de

Here's some more info: https://github.com/ryancramerdesign/ProcessWire/issues/1613 ryancramerdesign commented Language fields fallback to default when a localized version isn't available. This is one case where you may want to retrieve the localized value programatically. $value = $page->get('mytablefield' . ($user->language->isDefault() ? '' : '_' . $user->language->name));

Hi Soma, the Validator is still complaining about missing alt tags (in the theme templates)...

Hi, have you tried this? In the PW htaccess at the bottom, there are 2 rules. Try to comment out the one and comment the other. # ----------------------------------------------------------------------------------------------- # Pass control to ProcessWire if all the above directives allow us to this point. # For regular VirtualHosts (most installs) # ----------------------------------------------------------------------------------------------- RewriteRule ^(.*)$ index.php?it=$1 [L,QSA] # ----------------------------------------------------------------------------------------------- # 500 NOTE: If using VirtualDocumentRoot: comment out the one above and use this one instead. # ----------------------------------------------------------------------------------------------- # RewriteRule ^(.*)$ /index.php?it=$1 [L,QSA]

> As far as I know crawlers don't use Accept-Language typically, I had a problem with Wordpress recently. After the Google Update from last week, all translated pages got dropped from the index and their content was replaced with the default EN language content. A mega disaster. A fix was to switch off automatic language redirection (WPML). I am mentioning this here, because if this module is crafted on the above mentioned assumption that crawlers don't use Accept-Language, it might be interesting whether this is still the case and what the consequences are, if not. I am not a SEO specialist but I found this brand new article from 2016: https://support.google.com/webmasters/answer/6144055?hl=en So, what do you think?

I wonder if there such a quick way to sort and filter this? What about doing a next|prev|last|first roundtrips for an ordered selection of the page's siblings only? This does not work (always true): $prev = ($page->prev($myfilter)->id) ? $page->prev($myfilter) : $page->siblings($myfilter)->last(); $next = ($page->next($myfilter)->id) ? $page->next($myfilter) : $page->siblings($myfilter)->first(); There must be something wrong with my thinking here...

I wondered why the module wasn't working on included pages (like tablefield pages). I thought this to be a bug, it's not. The module actually works! - What actually was the problem was: The find section for identifying the pages which need work could include an "include=hidden". So all the hidden pages also benefit from this great feature. - Endless possibilities! UPDATE: Forget this message: Adding include=hidden makes no difference. I simply had a problem with my cache. Sorry. Is scheduler honoring the ProCache on status changes?