matjazp

Try with setlocale(LC_ALL,'zu_ZA.utf8');

Are you talking about the score on frontened or backend (admin)? As far as I know, you can't get A score since you need script-src 'unsafe-inline' and possibly 'unsafe_eval'. So, how you got A+?

PNG Optimization Tools Overview: https://css-ig.net/png-tools-overview

Oh, I never thought of that! Yes, local means on a computer (server), where PW is installed. Hmm, now I see how confusing can it be. What wording do you propose?

https://github.com/processwire/processwire-issues/issues/191 Yes, it use large amount of RAM and it's slooooow. I tried on windows, 5 MB jpg, peak memory usage was around 4 GB, CPU usage was 25% and it took 10-15 minutes (not seconds) to finish, src 6.020.543 bytes, dst 4.343.674 bytes.

I can't know that. Check the "Advanced options for local tools", the module shoud show you if (and what) optimizers are available on your machine.

That 404 is response from resmush.it web service, it happens sometimes. But the optimisation process should continue, regardless of the error - at least that's how its intended to be... As recommended, I would try setting pollTime from 100 to 500 in AutoSmush.js Installing local optimizers would save you sending/fetching the file to/from web service.

This one! Thanks @szabesz

I could, but that would give me all the files, not just images. And even I get the images by extension, I would have to know if image is of FiletypeFile of FieldtypeImage, and also would have to differentiate between originals and variations. If PW would store variations in DB... Also, I'm searching the forum and cant't find the post, where someone described (could be you?) how to iterate through a lot of pages (all of them) but without running out of memory and execution time.

Thx, diogo. Found out that find/findmany is very fast, it's getVariations() call where 95% of time is lost, probably due to filesystem calls (DirectoryIterator). I guess there is no way to improve that?

Any better way to find all images? The fastest way. Without script timeout. A lot of images... $timer = Debug::timer(); $allImages = array(); foreach (wire('fields')->find('type=FieldtypeImage') as $f) { foreach (wire('pages')->findMany("$f>0, include=all") as $p) { $images = $p->getUnformatted($f->name); foreach ($images as $i) { $allImages[] = $i; foreach ($i->getVariations() as $variation) $allImages[] = $variation; } } } $totalItems = count($allImages); echo "All images: " . $totalItems . " Timer: " . Debug::timer($timer);

Hi, Peter, sorry for late response, it was a busy weekend. Hm, that's unexpected error, it should only pop up if ajax call fail, but since 48 of images got processed ... Could you check /site/assets/logs/autosmush.txt and /site/assets/autosmush/progress.json if there is any clue? Check php error log. Also check the value of max_execution_time in php.ini and apache Timeout directive, maybe the script is timing out (I set it to 1 hour). Also please edit file /site/modules/AutoSmush/AutoSmush.js and change pollTime var from 100 to 500. I just tried with 70 images without problem. Bulk mode in the current state is not very good at processing large amount of images - 1951 is not large at all, but I never tested more than 100 images. Bulk mode needs complete rewrite, but since it worked good enough for small sites I just left it as is...

First, some background to lit a light. There are some functions in PHP that may produce unexpected results in special situations. This functions are used by PW core files and in user contributed modules. Some users may have problems with file upload (pdf, zip, image, whatever) if filename has non-ascii character at the first place. For example, if user upload a file named "år.jpg" (year in Swedish language), it is expected that PW would transliterate (transform) the filename to "ar.jpg", but because of the bug in basename() PHP function, the filename would become just "r.jpg". Nevertheless the file would upload successfully. But if the filename is "привет.jpg" (Hi in Russian language) the upload would fail. There are two ways how to handle this: Write and use custom functions instead of builtin functions Let end user fix that with proper locale Option 1. is used in some CMS/CMF (like Drupal), PW (Ryan) opted for option 2. After successful login PW perform a test and warning is issued in case of test failure. It is now your responsibility to set proper system locale. The locale is a model and definition of a native-language environment. A locale defines its code sets, date and time formatting conventions, string conversions, monetary conventions, decimal formatting conventions, and collation (sort) order. Those "problematic" builtin PHP functions are locale aware, that means they work as expected, if locale is configured appropriately. Locale can be set by the underlying operating system or in PHP. Because on shared hosting you don't usually have root access to the OS, the only option to set the locale is by using the builtin setlocale() PHP function. But, before you can use/set the locale, it must first be installed on the OS. On most unix systems at least some basic locales are already there, they are just not used. To check what locale are you currently using and what locales are available for you to use, create the file testlocale.php at the root of your website with the following content: <?php echo "<pre>Current locale:\n" var_dump(setlocale(LC_ALL, '0')); echo "\n\nAvailable locales:\n"; echo exec('locale -a'); Then point your browser to http://yourwebsite/testlocale.php If your current locale is "C" (and you are on unix), then you will probably get warning after login to the PW admin. What you want to do is change the locale to something that has "UTF-8" or "utf8" in the name of the available locales. In your case you would be looking for something like "sv_SE.UTF-8" or "sv_SE.utf8". Now, there is a chance that Swedish locale is not installed. You can ask your hosting provider to install it for you or use some other UTF-8 locale. On most unix systems I have seen, at least "en_US.UTF-8" or "en_US.utf8" is installed. If even that English locale is not available, then look for "C.UTF-8" or "C.utf8". And this is what you have to use as parameter in the setlocale() call: setlocale(LC_ALL, "sv_SE.utf8"); You could actually "stack up" multiple locales and one will eventually work: setlocale(LC_ALL, "sv_SE.utf8", "sv_SE.UTF-8", "en_US.UTF-8", "en_US.utf8", "C.UTF-8", "C.utf8"); Now, regarding where to put that setlocale() call. If you are not using PW multi language capabilities (you don't have Languge Support module installed), then you place setlocale to /site/config.php. That's it. If Language Support module is installed (PW checks for that), you have two options: Translate the string "C" in LanguageSupport.module for each installed language Put setlocale() call in /site/init.php My preferred method is option 1 and this is what PW (Ryan) recommends. See https://processwire.com/api/multi-language-support/code-i18n/ for more info on translating files. Option 1 allows you to set different locale for each of the installed language, while option 2 allows setting of one locale for all languages. PW will also provide links for the files that needs to be translated in the warning message. Ryan just pushed an update that makes it use the locale setting on the frontend when using LanguageSupportPageNames module (until now just language was changed, but not locale). Also setLocale() and getLocale() methods are added to the $languages API var.

1. No. 2. Why would you install language support if you don't need it? 3. sv_SE.UTF-8 4. echo exec ('locale -a'); Have to go now, will post more information/clarification of my brief answers later, stay tuned.

Location of setlocale() in /site/config.php is not important. What locales are installed on the system? What locale are you trying to set? PW version you are using? Please upgrade to latest dev (3.0.55). Is Language Support module installed? init.php is located at /site/ folder, create it if needed.

Is de_DE.UTF-8 locale installed on the other site?

As adrian pointed out, in multilanguage environment you have to put setlocale() in init.php, ready.php or admin.php since language support module will overwrite locale settings in config.php. Still waiting for response from Ryan about that.

If you would upload an image named "Ö.jpg", upload would fail. setlocale() solves this issue. This warning is echoed just in PW 3.0.53. You won't screw up your site, but it's possible that date/currency (and other locale aware) functions would produce different output.

https://github.com/processwire/processwire-issues/issues/184 If your server has Sweden locale installed (check with locale -a in shell), then you can use that, if not, try with what warning says. If you use ML put setlocale() in /site/init.php

@flydev me too, please

How did you change that? .htacces has nothing to do with that. You might consider reinstalling all from scratch, but that would not solve the mistery and would not satisfy my brain's grey cells (what's left)

This test just confirms that your .htaccess in picked up and parsed by apache, so the real problem still has to be in your original .htacces. The mistery for me is how it could work on friday and then suddenly cease to work on monday. Maybe you could post your .htacces file (zipped)? What PW version are you running?

Hm... how about simple test: create a new .htaccess file with the following: ErrorDocument 404 http://www.google.com/ and then pointing your browser to http://yoursite.com/foobar/ shoud redirect you to google.

23 20 2d are "# -" so it looks like .htacces is ok, but the first line of htaccess.txt from the latest dev contains ####### ... just comments. No idea from my side but if apache is logging those BOM charaters than it must read them from somewhere. Are you editing the right file /var/www/html/.htaccess ? Caching? Also, setup locale.

Just to be sure: head -c 3 .htaccess | hexdump -C doesn't show ef bb bf? Did you restart apache after change?