szabesz

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.

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.