• Content count

  • Joined

  • Last visited

  • Days Won


matjazp last won the day on November 18 2016

matjazp had the most liked content!

Community Reputation

152 Excellent

About matjazp

  • Rank
    Sr. Member
  • Birthday 04/27/1969

Profile Information

  • Gender
  • Location
    Maribor, Slovenia

Recent Profile Visitors

2,473 profile views
  1. 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?
  2. 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.
  3. 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.
  4. That 404 is response from 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.
  5. This one! Thanks @szabesz
  6. 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.
  7. 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?
  8. 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);
  9. 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...
  10. 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 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.
  11. 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.
  12. 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.
  13. Is de_DE.UTF-8 locale installed on the other site?
  14. 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.
  15. 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.