Leaderboard

Those subpages are now linked to your home page and you change your home page template to show what fields you want. For example, if your page reference field is called 'featured', in your home page template you can choose what fields you need to show from the subpage. <?php foreach ($page->featured as $apartment) : if ($page->featured->first->id == $apartment->id) : // it's the first one ?> <div class='featured first'> <h2><?=$apartment->title?></h2> <p>Bedrooms: <?=$apartment->bedrooms?></p> <p>Bathrooms: <?=$apartment->bathrooms?></p> <p>Price: <?=$apartment->price?></p> </div> <?php else: // it's not the first one ?> <div class='featured'> <h3><?=$apartment->title?></h3> <p>Bedrooms: <?=$apartment->bedrooms?></p> <p>Bathrooms: <?=$apartment->bathrooms?></p> <p>Price: <?=$apartment->price?></p> </div> <?php endif; endforeach; ?>

Some hook code is here:

Hello, Related topics that should give you ideas on how to implement such a thing: https://processwire.com/talk/topic/14273-can-processwire-do-this-user-management-profiles-search/ https://processwire.com/talk/topic/1755-users-login-to-separate-project-areas/ https://processwire.com/talk/topic/18395-user-admin-on-front-end/ https://processwire.com/talk/topic/16401-is-it-possible-to-login-to-a-user-from-the-frontend/ https://processwire.com/talk/topic/9811-frontenduser-login-logout-and-register-users-members/ https://processwire.com/talk/topic/13399-frontend-forms-for-users-to-input-and-update-data/

You could adapt this:

Unless I want to save the value of a page object's property in the database, I would not change a page object's property because it is reasonable to expect that a property corresponds to a value in the database. If I change the property but do not save it to the database, then from that point on it is "confusing" to keep track of the actual value of the property as its value is no longer "in sync" with the database (as long as we are talking about the same request being executed, of course). To tell the truth, I do not really get what you are trying to solve. I was just trying to point out a few things that might – but not necessarily – cause issues.

Maybe a sign that it's times for a break ?. Sometimes it helps to 'speak out your code' to determine if it makes sense. Have a look at that line. tableofcontents_table, I assume, is your Profields Table. Reading that out loud, your code is saying, find me siblings (PLURAL) of this page and get me the value of its (SINGLE) tableofcontents_table field. Doesn't sound right, does it? It's like saying 'find me 10 oranges (PLURAL) and show me its (SINGLE) price. That's wrong. The question would be, which orange's price? We have 10 oranges here! It should read, 'find me 10 oranges (PLURAL) and show me their (PLURAL) prices. Aha, so, we are dealing with a collection. Any collection has to be iterated (foreach) to get each members individual value. Alternatively, you could ask for the first(), last() or nth() orange to deal with one member only. OK, so I need to get some sleep too. The docs say this about $page->siblings(): $toc is a PageArray. If you run this in Tracy console: <?php d($page->siblings("template=tableofcontents")->tableofcontents_table);// null You will get the value null, hence your error message since you are doing this null->render(). Now for some unsolicited advice ?. TracyDebugger is your best friend. The table clearly is there and clearly is a sibling and its template is as stated and the table also. Whilst this might be the case, it is best to always check if your selector/query returned something (and its type) before you start working with it. Hope this helps. ps: Profields Table has its own VIP support forum, accessible to you if you have a current subscription

I added a feature for this in todays 0.3.0 (not pushed the release tag yet, as there was a lot of rewriting to implement this feature). If you want to show an opt-in element instead of the consent-required element, just add a data-attribute data-ask-consent="1". Here is an example: <iframe src="" data-src="https://www.example.com/" data-category="marketing" data-ask-consent="1" frameborder="0" height="400" width="400"></iframe> In this case, the iframe gets only loaded, when cookies of type "marketing" are allowed. If not, the user will be asked for consent. The text of the consent-window is configurable in the module config. The markup of this message also includes an css class with the type of cookie, if you want to style them specifically. privacywire-ask-consent.mp4

Last week I told you how I was working on a getting a new Stripe payment method working with FormBuilder… and I’m still working on it. That wasn’t exactly the plan. Stripe isn’t quite as easy to work with as it used to be, or maybe Stripe thinks I’m not as easy to work with as before. Either way, I’m learning, and it’s been a good opportunity to expand FormBuilder with its own class for plugin “action” modules. Hopefully some of this work on the Stripe side can apply for other payment methods, or any type of action you’d want to take with a form submission. It’s probably going to take another week or so before this module is ready to release in the FormBuilder board, but it’s going to be built well and accompany a new version of FormBuilder too (that supports these plugin actions by way of PW modules). Having these actions as ProcessWire modules opens up new doors for FormBuilder, and I may even move some of the built-in actions (like saving to Google Sheets) into this type of module, which would be nice for hooks and maintainability. There’s not a lot to report on the core side this week. There are a few commits and improvements, but not yet enough where I’m ready to bump the version to 3.0.168. One small but useful improvement is that handling of selector queries for words with apostrophes has been improved. One of my clients noticed they were having trouble with their site search engine matching terms like “Alpe d’Huez” and “L’estello”, and so our page finding engine has been improved to narrow them down with the fulltext engine and then find the exact matches with regular expression queries. This improvement enhances most of the partial text matching operators. It also solves the issue of there being different kinds of apostrophes (ascii straight vs utf-8 curly), among other things. Overall the core is running running very smoothly on the dev branch, so I’m thinking we may try and do another merge to master before 3.0.170. Thanks for reading and have a great weekend!