szabesz

Welcome to the forum @bkno Just one consideration to add to the others written above: most likely you will only be forced to update an otherwise smoothly running ProcessWire website when the PHP version it is running on becomes obsolete and the new PHP version you wish to upgrade to has deprecated methods no longer supported/available but some functionality of your old ProcessWire depend on those deprecated PHP functions, meaning you will need to update your ProcessWire core and other modules in order to keep up with the changes in PHP. Sure, it is a general issue with PHP based websites, but since you asked how frequently you need to update, I think it is worth pointing out that due to the nature of PHP one day you will be forced to update or at least want to update if some PHP security flaws emerge in no longer supported PHP versions. Other than that, you do not have to update at all That being said, I recommend updating when you need new features provided by the core or when you want to upgrade to a PHP version which dictates the need of upgrading ProcessWire. Hope this helps.

I guess it was not adjusted to the new environment: https://processwire.com/blog/posts/amazon-aws-now-powering-processwire.com-sites/ also, automatic "version string" update seems not to be working here (related maybe?): https://processwire.com/download/

+1 Something else must have happened too "about at the same time". Setlocale is used so that the system can handle certain utf-8 characters properly when uploading files. What sort of characters does your client use when naming files to be uploaded? Maybe you set it to en_US.UTF-8 and soon after they uploaded something not supported in this character set? I think it is quite unlikely to be the issue. You might want to figure out what else could have happened.

I'm glad to hear it was easy to solve.

Hi, I would consider taking a closer look at this one: Product variations are challenging to implement properly.

Hi, Some ProcessWire developers already use Snipcart: https://snipcart.com/list-ecommerce-payment-gateways I am also developing a site with eCommerce capabilities, but I have not yet reached the stage of dealing with Snipcart, currently I'm building the basics (database and some templates, etc...). Snipcart supports Authorize.Net which I need and use in other non ProcessWire sites, but it also supports "European merchants" listing Paymill and Mollie. I do not know how reliable the latter two services are, but Authorize.Net is solid. And Snipcart is not only a payment provider but a lot more, so I expect that I will be able to cut down on development time considerably.

Hi, the blog works by using page()->children... etc. (see blog.php). When switching the template, the children will be the pages under Home which are not pages of blog-post templates, so there are no comments (among other things) to display. You need at least to look for the selector(s) being used by templates, and change them accordingly.

Thanks for the tip! Now I just have to decide which way to go

Thanks for sharing @clsource! Seems to be a popular topic these days. Have you seen this one?

Maybe I was the first one who tried not to do it BTW, can it be considered to be a bug? What do you – and others reading this – think, should I open a new issue for this at GitHub? Or it just the way it should be: installing all languages modules is required. Full stop

Thank you, you seem to be right! I installed the module and all the others required by it, and the label showed up. However, maybe it is just me who does not understend the description, but it sounds to be the opposite: "Field that stores a page title in multiple languages. Use this only if you want title inputs created for ALL languages on ALL pages. Otherwise create separate languaged-named title fields, i.e. title_fr, title_es, title_fi, etc." So that is why I though installing the module Languages Support is enough in the case of language-alternate fields. I do use AOS, but whenever I have an admin issue, that is the first I turn off temporarily to make sure it is not the culprit.

I must be missing something important here. Where are exactly those label setup fields? I cannot see them.

Hi @AndZyk, You mean the Default/Hungarian label of the language-alternate field called title_hungarian in Setup > Fields? If so, the answer is yes, I did provide both labels but it does not make a difference. Do you happen to have a/some working site(s) with language-alternate fields where the extra labels show up as seen int he demo video? BTW, I'm thinking of switching to Multi-language fields but that generates language variations for image descriptions which I do not need, so some simple language-alternate fields would be enough for me. cheers, Szabesz

Hi, This is the first time I'm setting up "Language alternate fields". I was following the docs, especially Ryan's demo: www.youtube.com/watch?v=eq-9GQCT0lw In the demo Ryan points out that ProcessWire should add a "little label" displaying the language being used for the language-alternate field (signaling that ProcessWire identified the field as a language-alternate one). I have setup my field as seen in the video, but the extra label is missing as you can see it in the screenshots: Any idea what is going on? I would like to see the label to make sure my setup is ok before I proceed.

userAuthSalt: " it is forever tied to the passwords as a secondary salt." But if you use the very same database and files normally you should only need to update $config->httpHosts as @Sérgio Jardim pointed it out above.

Did you also uncomment this one? # ----------------------------------------------------------------------------------------------- # 9. If you only want to allow HTTPS, uncomment the RewriteCond and RewriteRule lines below. # ----------------------------------------------------------------------------------------------- # RewriteCond %{HTTPS} off # RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

I edited my previous post too by adding this one to it:

I'm not an .htaccess guru, but I dug up this one from the forum some time ago (sorry, I dunno where it was posted and by whom): # inserted before the block "# 13. OPTIONAL: Redirect users to the 'www.' version of the site (uncomment to enable)." # ----------------------------------------------------------------------------------------------- # OPTIONAL: Redirect users to the non 'www.' version of the site (uncomment to enable). # For example: http://www.processwire.com/ would be redirected to http://processwire.com/ # ----------------------------------------------------------------------------------------------- RewriteCond %{HTTP_HOST} ^www\. RewriteCond %{HTTPS}s ^on(s)|off RewriteCond http%1://%{HTTP_HOST} ^(https?://)(www\.)?(.+)$ RewriteRule ^ %1%3%{REQUEST_URI} [R=301,L] This is for non www of course, but it works for me on cPanel shared hosting sites. I do not like www, so I never tried the opposite. EDIT: I've found the source:

Thanks @clsource. I've just hit +1 at GitHub. Anyone else to make this one more prominent over there?

Thanks for sharing! I do like the design although the heavy usage of eye candies is a bit too much for my taste. A couple of artifacts I noticed in Mac Chrome: [...old and big image, I removed it to save space...]

This is great, thanks! May I have a suggestion too? Searching by name is one thing, but what if we could search by "tags"? I mean lots of icons can be used in different contexts, and most of the time I cannot even guess the name. For example I use "Car" for the article excerpt/ledes (in a "leading the way" sense). More examples I use: Trophy => bagde, Fire => effects, Compass => sku, etc... These associations could be (hard?) wired into the module, so that you can make search possible this way too. I would be happy to contribute, or even better, you could somehow make it possible for everyone to contribute.

Just for reference, now we have (thanks @Robin S):

Maybe a color management / color profile issue? http://www.color-management-guide.com/web-browser-color-management.html I think it is still best to stick to sRGB. I do not think that with mainstream monitors we will ever be able to expect that people out there will see the "same" colors as we do on our own screen.

@Chamche First of all, ask your hosting provider to turn off ModSecurity, or they should let you know the .htaccess rule(s) that need to be added to the beginning of .htaccess. There is no need for mod_security if you use ProcessWire with the .htaccess file it comes with.

Welcome to the Forums, @Chamche Any error messages to share with us: PHP, apache? Also, what is the output in the browser?