Sergio

Why not a simpler one, like: ^\d{4}-\d{4}$ ? Does anybody see a problem with this approach?

Check the owner and permissions on site/assets/* And if you want to learn more server stuff, there are a book and a video tutorial series on https://serversforhackers.com/

As you're using Nginx in front of Apache, maybe it's worth to try this: https://github.com/mariusv/nginx-badbot-blocker

Disk swap is needed when some portion of disk space must be reserved to be used when the system RAM is full, so the disk acts like RAM (although much slower). The default is zero on a fresh Ubuntu install and for lower RAM servers like this one should be at least the double (it's recommended 2GB for 512MB). Serverpilot (that you're using) enables 512MB only: https://serverpilot.io/community/articles/swap-is-enabled.html So I recommend you to log as root and increase it. https://www.digitalocean.com/community/questions/how-to-change-swap-size-on-ubuntu-14-04 And look here too: https://www.digitalocean.com/community/tutorials/how-to-add-swap-space-on-ubuntu-16-04

Good point. Check for spiders on the log.

Maybe a silly question, but is Swap enable and is it at least 2GB?

Imagine this case: - The site has English as default language and Portuguese (pt-PT) as an alternative and you decided to suppress the language code on the URL, like in your example above. Everything looks fine but a new page is added with a name that is ambiguous, like '/actual'* (which is a false cognate, as it means 'current' in Portuguese). Event if PW's handle the routing fine, what about the users? What language is the page in if they only see the URL? So, a pt/actual/ will be better. * 'Actual' is used just as an example, as it's now spelled 'atual', after Portugal, Brazil, and other Portuguese-speaking countries agreement on vocabulary issues back in 2008 I think.

I agree with @tpr on avoiding utf-8 URLs, like, "/pt/apresentação/" for (/presentation) as there's no real need of it for Portuguese. Avoid flags to represent languages unless you're targeting a specific country > language. Eg. Brazil's flag for text is in Brazilian Portuguese, not Portugal's flag and vice-versa. This is only a UX good practice, though. Language switcher is fine. PW's language profile is a good example, although you can only show the language's abbreviation instead of its full name, so EN and PT are fine. I still prefer PT instead of BR unless you will have both Portuguese versions of the site, in this case, use BR ou pt-BR / pt-PT. Regarding the domain, Google has a good documentation about it: https://support.google.com/webmasters/answer/182192?hl=en

I think it depends on your content approach. For instance, if the client has a complete operation in Brazil, it will be great to both users and SEO to have the URLs also translated like so: example.com/about-our-products example.com.br/sobre-nossos-produtos (.br is optional). example.com/pt/sobre-nossos-produtos (.pt can also be "pt-br" or "br" if you are targeting specifically Brazilian Portuguese speakers) But in the case of just translating the content (not fully localizing it to the market) and/or you already have a bilingual site with the same English URLs, keep them in English only. And on the topic, avoid at all costs using country flags on the front-end. Unless you're targeting specifically like I said.

Check the homepage settings and see if the language is active there.

I just saw this: http://lifehacker.com/5896830/use-google-docs-to-monitor-your-websites-uptime Use Google Docs to Monitor Your Website's Uptime Have a website and want to know the minute your site is down? This simple Google Docs spreadsheet from Digital Inspiration can email you and monitor your website for free.

Hi Teppo, sorry for the lack of detail. I'm only using their server monitoring service, monitoring two Ubuntu servers running PHP, Apache, etc. and Wordpress and a MySQL server. I installed it a couple of years ago so I don't remember if the pricing info was clear at that time, but AFAIK the server monitoring is still free, as mentioned in this article of Jan, 12. I'm not using it to monitor my servers running ProcessWire yet though. :|

I use https://newrelic.com/ and it's quite nice, even on the free plan (which I use).

Loved the design! Very good execution as well. Congratulations! The only problem is the scroll highjack. I can understand the decision, but it's a pet peeve of mine.

Are you doing a fresh install? Tell us more.

Mike, I'll be doing some tests on my multi language install (that one we talk about in the earlier posts) but I'm afraid I can only start it in one week or so because of my other projects. But I'll let you know.

@szabesz is correct. The language option on the User is for the backend access only. @A.Schmidt your setup is correct. When the guest user access the homepage using just "/' Processwire will show the default language, in this case, English. Using "/de" will show German. This is how PW works. And there is no redirect either. If you want to redirect based on browser settings and other stuff, there is a module for that . But I don't recommend it as it a UX flaw in most cases, so you have to be careful.

Excellent news, Mike!! Thanks!

Very interesting template setup with all the params and helpers, @clsource!

Hum... you can remove the style and scripts folders inside templates/ as you are not using them. But if you have the css and js file inside 'assets', maybe the error is from using PHP shortcode syntax to echo the path on: <?= $config->urls->templates; ?>assets/ Try using: <?php echo $config->urls->templates; ?>assets/

And also, just to be sure, are the assets files there on the server??

Looks like a permission problem. What's the permission on the asset folder?

I suspect it's a CPanel config then. Can you create a subdomain like dev.domain.com and move the files there?

One question, did you move the .htaccess to the devel folder? I just tested a PW local installation here, running on MAMP: 1 - It was running under pw-multilang.dev with default config.: My config.php has $config->httpHosts = array('pw-multilang.dev', 'www.pw-multilang.dev'); 2 - I created a 'devel' folder inside the folder and moved all files, including the .htaccess, to it. Checked http://pw-multilang.dev/devel/ and all good, assets loaded and all pages accessible, including admin. 3 - I did another test, changed the base on .htaccess to /devel/ and all was good too. http://pw-multilang.dev/devel/ kept working. ---- Did you do anything else I didn't?

How are you linking to the assets? Like the default {$config->urls->templates}assets/ ? And can I see your .htaccess and config.php (remove the password, of course) ?