szabesz

Yep, cPanel does provide access to the user's root directory which means "access outside of the web-root", and with enough extras/plugins enabled/installed for it a cPanel account can be highly configurable.

It is still confusing to have this feature nonetheless as we are required to post our Pro module support requests in the appropriate forum topic – which is a reasonable requirement –, so this support tab thingy (whether it is integrated part of the forum software or not) is still misleading, in my understanding.

display: none; ?

+1 another + 1

(from) $30/month? Maybe it is worth it, hard to tell.

While I agree that a one and only "official store" would be great and help ProcessWire to prosper, I suggest that developers willing to sell such modules should unite Consider that Ryan is a human too, with only 24 hours a day to use up meaning: implementing, maintaining and running the store requires extra effort and time which might be a mayor constrain here, hence my suggestion of doing it as a teamwork and sharing the benefits as well. Currently we have: https://processwireshop.pw/ and https://processwire.com/talk/store/ Although it would be welcome to see the two "merged", I guess it is not as easy as it sounds.

Hi, @HMCB This blog post by @clsource should clear things up a little bit: https://medium.com/@clsource/understanding-processwire-templates-fields-and-pages-201aecd0a1a4 When talking to clients, you might want to mention that in the ProcessWire world a Page (=> "special PW terminology") represents a database record. Most of the time it is just enough for them to know as most of them are not skilled enough to digest too much in this regard. Since you are free to label/name your pages whatever you want to (using some appropriate names, of course), you should do so and when talking to clients just refer to those "pages" by using their labels/names.

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: