LostKobrakai

I think processwire does always search in the language the user currently does have activated, so you'd probably need to switch through all languages and do a find while each of them is enabled (at least temporarily).

You cannot access php files inside the site folder. You'd need to use the url of your settings template page.

Just to add onto your explanations: sprintf does also support reordering of arguments, but still with an awkward syntax: $out = sprintf(__('Your city is %1$s, and your zip code is %2$s.'), $city, $zipcode); // Translated like this $out = sprintf(__('Your zip code is %2$s, and your city is %1$s.'), $city, $zipcode);

Can someone of you guys test out the new commit of Ryan? My project with that issue is currently stuck on 2.7.

Yeah, everything before line 13 shouldn't be there.

The pagelist does issue an ajax request, which when met with an unexpected result (not json) will show this error. Take a look in the browser devtools network tab to see what's being returned. Most likely it's some kind of php error or notice.

$input->whitelist does not store values. It does just mark $input variables of the current request, so they can be appended to (pagination) links as ?my_data=xyz variables, which on the next request can be read again. If non of those links is clicked the values are gone. The most prominent use case is preserving any user filter values while going through pages of results. Having the values in the url also makes sure you can send that url to your peer and he or she can open it as well. Anything you don't want the user to see/modify you'd use the session.

Translations or changes in the default language of static texts (like your placeholders/labels) should be done with the right tool, which in case of processwire is the language support module. Use Pages for dynamic content (and longer texts).

The various module update notices you're seeing when loading any new module don't have to be of your concern. The files are already there, just the needed db changes (if any) will be triggered on demand. These should cause no problems and happen without any user interaction.

Yeah, but google would also only index a single page. If that's what you want then go for it.

$m = $mail->new(); $m->from('noreply@yourdomain.com'); $m->to('alexpi@yourdomain.com'); $m->header('Reply-To', $emailBackTo); $m->send(); Like I said in the WireMailSMTP modules topic: If you use such a service do not send emails with a "From" address, which is not your own.

Modules will all be refreshed as soon as they're used for the first time. That's why you get those notifications again and again.

Disallowing /about/ is probably not a good idea. /about/ should load the correct content inside your single page app.

Do also cache the total/start number aside of the returned page array and use $pa->setStart() and $pa->setTotal() if you hit the cache.

Yeah, wasn't to confident as it has been around a long time as issue on the old repo

I really feel this should be fixed, especially as the OR group syntax does work.

Had to search hard, but found it: https://github.com/ryancramerdesign/ProcessWire/issues/1232 Edit: And the new one: https://github.com/processwire/processwire-requests/issues/17

I'm not 100% sure about 3.0, but I've a 2.7 installation, where this caused me so much trouble I know for a fact that it doesn't work.

Send them from your own domain and just set the Reply-To header to the email of the contacting person. Automatically sending emails in the name of others isn't in vogue anymore with all those spammer out there.

has_parent does not support multiple alternative values with pipes. Only "hackish" version is to use OR groups like so: (has_parent=$cat1), (has_parent=$cat2)

Security doesn't magically get better just because files are outside the webroot. The .htaccess file does already block all access to critical files inside the processwire installation and all those files must be accessable by the webserver/php anyways, which makes things equally vulnerable in terms of those security holes which let an attacker execute his own code. And as you said for lots of hosting services it's not even an option to put library files outside the webroot. Obfuscation of the system also doesn't really improve anything considerably. Ask all those people here tracking how many attacks on wp-login.php they get even though their sites are obviously not wordpress sites. As soon as security issues are known they'll be tested no matter of how hard you try to mask your underlying system. It's already possible to share the wire folder for multiple sites, but it's to be considered that all pages also need to be updated at once, which at least for me is rather a downside than an important feature. But still this is already doable. Regarding the assets folder. ProcessWire does have a config to protect the whole assets folder essentially piping all requests to files through php to ensure access is granted for each one. If you only need to saveguard some files and prevent the php overhead for the others you can install the 3rd party "SecureFiles" module, which let's you put files out of the webroot when using this fieldtype. In regards to your point about static site generators. ProcessWire is different to Laravel in that it does depend on a database. And not only an empty one, but there need to be things installed to run ProcessWire. That's not really useful if you want some static site. If you only want html output to be generated from db data you can already use ProCache to serve static html to users with the full power of processwire to generate that html.

Are you using 2 factor authentification? If so make sure you generate an app password instead of using the account password.

Take a look here: https://processwire.com/api/ref/pagefile/description/ and here: https://github.com/processwire/processwire/blob/35df716082b779de0e53a3fcf7996403c49c9f8a/wire/core/Pagefile.php#L300-L310

For a complete documentations of $mail take a look here: https://processwire.com/api/ref/wire-mail/ $mail does also use mail() internally if you don't use any 3rd party WireMail module. I'd suggest you to install one of them to not send your emails from php directly. If you still get spam flags then you should look into email domain verifications like SPF or DKIM and maybe use one of those email testing services to analyse your sent mails for other spam triggers.

First of all it's always good to upgrade in major version steps, so in your case from the original version to 2.6 -> 2.7 -> 3.0. But in your case I'd try a Modules > Refresh and clear the browser cache afterwards.