szabesz

As far as I can see, it is set in Session.php: https://github.com/processwire/processwire/blob/master/wire/core/Session.php#L263 ... if(ini_get('session.save_handler') == 'files') { if(ini_get('session.gc_probability') == 0) { // Some debian distros replace PHP's gc without fully implementing it, // which results in broken garbage collection if the save_path is set. // As a result, we avoid setting the save_path when this is detected. } else { ini_set("session.save_path", rtrim($this->config->paths->sessions, '/')); } } @session_start(); ... So I guess it is possible to set it in config.php with $config->paths->sessions, see I tried it with absolute path and it works for me, e.g.: $config->paths->sessions = "/Users/user/MAMP/siteroot/site/assets/mysessions"; I think "/tmp" can be the system default which gets purged so that is why you have issues with it. But I'm just guessing, I'm not a Linux admin kind

Hi, Did you check where session files are actually saved? Eg.: https://stackoverflow.com/questions/4927850/location-for-session-files-in-apache-php

Hi, As far as I know, since ProcessWire 3.0.29 we have RewriteRule "(^|/)\.(?!well-known)" - [F] there by default. See: https://processwire.com/blog/posts/pw-3.0.29/#summary-of-added-pull-requests

Hi, related discussion and hints here:

==

I'm glad you got it working. Just a hint: by duplicating code we make it harder for ourselves to maintain it: http://deviq.com/don-t-repeat-yourself/ I always try to avoid it whenever I have the time to do so (sometimes we just don't...).

Oh, sorry for the early morning typo, I left <?php endif; ?> in the example, but <?php endforeach; ?> is needed instead, of course. I'm not good at writing code in the browser, I'm missing my IDE's help

Hi, FYI, Adrian is still away for a few weeks, see:

Hi, not tested, but the issue with your code is that you check for empty link before the for loop and not inside of it, so something like this should do: <?php foreach($page->Slides as $Slides): ?> <?php $image = $Slides->images->first(); if ($Slides->Link) { $link = 'data-link="' . $Slides->Link .'"'; } else { $link = ""; } ?> <li data-transition="<?php echo $page->Slide_Effect; ?>" data-slotamount="7" <?= $link ?> data-target="_blank" > <img src="<?php echo $image->url; ?>" alt="<?php echo $image->description; ?>"> <div class="tp-caption" data-x="100" data-y="115" data-speed="700" data-start="1000" data-easing="easeOutBack"><h2><?=$Slides->title ?></h2></div> </li> <?php endforeach; ?> BTW, templates and fields should be named lowercase in the admin, so that you can use lowercase identifiers for your attributes/properties in your code which is a convention for such entities.

If you want to confuse beginners, why not I push it a bit further: the "simplest" creature which can be said to be alive is a single cell. It IS life. In order to boost the chances of survival cells unite, live and die (disintegrate) "together". The fundamental unit of life, the cell, is alive when it first begins to move against gravity and the path of least resistance.

Also, you can use @adrian's Tracy Debugger module to use different template files temporarily: https://processwire.com/blog/posts/introducing-tracy-debugger/#template-path-panel

What needs to be checked depends on the field's Formatted value setting: So when there is the possibility of getting null the code must account for it, you cannot just call first() "first"

+1 Thanks in advance!

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.