matjazp

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?

Double check your .htacces file as it looks like UTF-8 BOM issue.

It would be helpfull if we could see your template files and includes (like footer.inc), I suspect there's still some mistake there - Oculi plus vident quam oculus

You changed the ownership of files, what are their permissions? Is apache really running as www-data user/group? Anything useful in /var/log/apache2/error.log ? Maybe this could be helpful: http://askubuntu.com/questions/767504/permissions-problems-with-var-www-html-and-my-own-home-directory-for-a-website

Could you try simple if/else instead of ternary: if($small) $template = new TemplateFile($config->paths->templates . "markup/events.inc"); else $template = new TemplateFile($config->paths->templates . "markup/event.inc");

Sorry for troubles. Please upgrade to 1.0.6 if that fixes it (just uploaded to github).

https://github.com/processwire/processwire-issues/issues/110

Yes, this is how my site config.php looks like: /** * Installer: File Permission Configuration * */ $config->chmodDir = '0770'; // permission for directories created by ProcessWire $config->chmodFile = '0660'; // permission for files created by ProcessWire $config->fileCompilerOptions = array( 'chmodFile' => $config->chmodFile, 'chmodDir' => $config->chmodDir, ); That's an installer issue, it should add those two settings in /install.php after line 716.

When FileCompiler,php compiles a file, the permissions on the compiled file/directory at /site/assets/cache/FileCompiler/... is not correct. It's 0644 and not what I've set in /site/config.php with $config->chmodDir and $config->chmodFile I can overcome this by puting this in /site/config.php: $config->fileCompilerOptions = array( 'chmodFile' => $config->chmodFile, 'chmodDir' => $config->chmodDir, ); Now, I see that there is $config->fileCompilerOptions in /wire/config.php: $config->fileCompilerOptions = array( 'siteOnly' => false, // only allow compilation of files in /site/ directory 'showNotices' => true, // show notices about compiled files to superuser when logged in 'logNotices' => true, // log notices about compiled files and maintenance to file-compiler.txt log. 'chmodFile' => $config->chmodFile, // mode to use for created files, i.e. "0644" 'chmodDir' => $config->chmodDir, // mode to use for created directories, i.e. "0755" 'exclusions' => array(), // exclude filenames or paths that start with any of these 'extensions' => array('php', 'module', 'inc'), // file extensions we compile 'cachePath' => $config->paths->cache . 'FileCompiler/', // path where compiled files are stored ); But, isn't /wire/config.php read first, and then /site/config.php and thus my config settings are ignored? I guess it's expected that we should set specific fileCompilerOptions but I think it could be misleading if we setup proper chmod in /site/config.php and expect that this would be honoured?

I did Please use the latest version from github.