Leaderboard

1. Create all the fields you need relating to a single car. One field you don't need to create is "Title" because that is a global field that exists by default. 2. Create a template "car". To this template add the fields you created in step 1. This is the template that will output the fields for a single car. 3. Create a template "cars". This is the template that will output the list of cars. If it only outputs the list of cars it may not need any fields added to it apart from the default "Title". 4. Create a page "Cars" that uses the template "cars". 5. Create a child page of "Cars" for your first car that uses the template "car". Fill out the fields. Repeat this step for all your cars (see end of post for a time-saving tip). 6. Create template file "car.php" in /site/templates/. In this file output your fields as needed, getting each field as $page->my_field_name 7. Create template file "cars.php" in /site/templates/. In this file you will get a PageArray of all the cars and then loop over them to create links to the individual car pages. // get PageArray of all cars $cars = $pages->find("template=car"); // in this example you could also get $cars with: $cars = $page->children(); // Output list of links... if(count($cars)) { echo "<ul>"; foreach ($cars as $car) { // $car is the Page object for an individual car // You can get any field of the car with $car->my_field_name echo "<li><a href='{$car->url}'>{$car->title}</a></li>"; } echo "</ul>"; } Time-saving tip: you could import data for your car pages in bulk from a CSV using this module.

I think I'll go with this syntax for the page thumbs: { "featured_image": "template=wine|basic-page, children.count=0, parent!=1", "bg_image": "" } The idea is to use different fields (eg. "featured_image") and filter them with selectors. The first matching selector will be used. In this example featured_image is used on matching pages, and bg_image elsewhere. I may modify the syntax to something that is easier to use. If only a string is entered, it will be treated as a global field to use on all pages.

Hi Nico, Welcome to the forums. Just wondering why you don't want to use the backend to edit your pages. My take is this: the whole point of the frontend edit features is that you stay on the page being edited. If you are navigating to a separate page for editing then that might as well be "Edit Page" in the backend - no need to reinvent the wheel. You can display a link to Edit Page in the frontend only to users who may edit the page: if($page->editable()) { echo "<a target='_blank' href='{$page->editURL}'>Edit this page</a>"; } Or if you wanted to keep the /url/to/page/edit/ scheme you could redirect to Edit Page: if($input->urlSegment(1) == 'edit') { if($page->editable()) { $session->redirect($page->editURL); } else { throw new Wire404Exception(); } }

Wow finally I can answer internet is quite slow at the moment and the new PW forums seem to be a little hungrier or dependent to load fully for the reply form to work/load so I can read but answering is a hard task for me..and here's now link anymore pointing to a stand alone reply form (which could maybe be more lightweight, I don't know..) anyway..now it works So as @kixe requested the policy link text is now translatable, too. I'm not sure but I think till now the translations weren't reflected in the cookie notification at all, or maybe I confused myself and missed something don't know.. Anyway now it works (at least for me). Don't know if this is the proper way of coding this and I'm open to suggestions, maybe there's a PW way in doing this? And as I'm a little more gitty now (working more with git, just found out what gitty actually means haha^^) I included a devns branch now..maybe it's a little confusing? (just now came the idea to call the branch namespaced or something) as it's not the development version of MarkupCookieConsent but the namespaced version meant to be used with PW 3.x devns. So the only difference is added namespace in the module and the config file and module info now reflects the need for PW >= 3 to install the devns branch

Hello @Mercury and welcome to the forums, Do you really want to use MySQL queries? Why not the API instead? See, for example: https://processwire.com/api/selectors/ I do not know what you have read/watched so far, but probably the best article to start with is this one: https://www.smashingmagazine.com/2016/07/the-aesthetic-of-non-opinionated-content-management-a-beginners-guide-to-processwire/ A tutorial that I can also recommend (among other things it utilizes the twig template engine which you might not need, but other important concepts are also demonstrated): http://blog.mauriziobonani.com/processwire-basic-website-workflow-part-1/

A series (currently 10 episodes) of video tutorials in German by Leonid Lezner https://www.youtube.com/channel/UCwkKKtIeOzfIqF8X5gNP0_g

Dynamic Selects Released 27 July 2016 Dynamic Selects is a commercial module that enables the creation of dynamically related/dependent ajax-driven chained dropdown lists (aka cascading selects) for display and storage of multiple types of data. The module can be used both in the front- (display only) and backend (display and storage of data). Setting up Dynamic Selects is very easy. With minimal effort, site developers can set up simple or complex chained selects. By making a selection in a trigger dropdown, via ajax, values are fetched and dynamically populate options in the dependent select. In turn, making a selection in the now populated select triggers the same action further down in a dependent select. The module only uses/stores ID references to selected options in the selects meaning the most current/up-to-date data will always be displayed in the selects. Currently only ProcessWire managed data are supported. If there is enough demand, we may incorporate external data sources (typically JSON). The module consists of 4 modules ProcessDynamicSelects MarkupDynamicSelects FieldtypeDynamicSelects InputfieldDynamicSelects Video Demo: https://youtu.be/wkhx8xQ5ue4 Documentation: http://dynamicselects.kongondo.com/ Shop: https://processwireshop.pw/plugins/dynamic-selects/ Requires: ProcessWire 2.5 or newer and jQuery if using the frontend module (MarkupDynamicSelects) Features Easily create powerful ajax-driven cascading/chained selects/dropdowns Unlimited number of select dropdowns per field Data-mapping made easy thanks to multiple possible combinations of data relationships, triggers and sources Mutlipe data relationships to chose from ID-based data referencing ensures your data values always stay fresh Remote and local caching to speed up data access and reduce ajax-requests to server User-friendly, intuitive and easy to set up IMPORTANT Before using this module in the frontend, you will need to thoroughly read the security section in the documentation.

Hi, You can just use a general image (as a placeholder) from your .../site/templates folder when an image is non-existent. You can check the existence like: if($page->image) { // an image is present } https://processwire.com/api/fieldtypes/images/ If you do not resize an image, via what sort of link do you want to "link to" a nonexistent resized version of it? Sounds like a contradiction. Am I missing something? As far as the speed of image resizing is concerned, if you have ImageMagic on the server and you are using the latest 2.8.x or 3.0.x versions ProcessWire, you might be able to solve it by enabling the IMagick module: https://processwire.com/blog/posts/processwire-3.0.10-expands-image-resize-options/

I think you should create a thumbnail on after saving the image with a hook. see https://processwire.com/api/hooks/captain-hook/?filter=image <?php // hook to this method protected function ___fileAdded(Pagefile $pagefile); $this->addHookAfter('InputFieldImage::fileAdded', $this, 'createThumbnail'); // create the thumbnail public function createThumbnail(HookEvent $event){ $file = $event->return; // new thumb $page->image->width(200); } with that you create the thumbnail right away on image uploading. I think that would work. But haven't tested that code.

Works on 3.0.28

I would not necessarily rely on composer being installed. But you can use the new psr-4 classloader of processwire, which is shipping with 2.8/3.0. $classLoader->addNamespace('MyNamespace', $config->paths->templates . "includes/"); And if you want your module to work in both 2.8 and 3.0 simply do not use the ProcessWire namespace, which will be dynamically injected by the module/template compiler in 3.0.

Right, so I've made a few more developments to my test-phase, and am now ready to begin porting this to a fresh module setup, which is going to be based on something I'd setup a while ago. I intend for it to run in namespaces (Jumplinks\Something\Etc) and use traits. It'll also make use of its own autoloader. Now, I'm not sure if using my own autoloader is the correct approach. I see that both 2.8 and 3.0 have Composer support, but not sure on the Composer-based differences between the two - could someone enlighten me on that? Also, I assume I can work on the module in 2.8 only and it will be fine in 3.0? The only difference is the fact that 2.8 doesn't use the ProcessWire namespace, right?

Very good! When the field isn't autojoined, ProcessWire effectively lazy-loads it and it just occurred to me that this wasn't happening when the collection is iterated over by the Twig code. When you set a field as autojoined, it eager-loads it; sometimes, you may not ever touch the field when you are rendering data so, it makes sense to not load it with a page if you aren't going to generally output the value. It's a decision that you would make on a field by field basis but in normal terms, I suppose you would always want the body field to be loaded and therefore set its value to autojoin. Cheers!

Yes it did!

@Gazley you're the man Thanks

Hi @Manaus, Just a SWAG but, do you have Autojoin checked/ticked in your "body" field definition? If not, select it and see if this makes a difference.

@szabesz I use Soma's Page List Image Label module often and I think it would be nice having this feature inside AOS. While at it, I'll implement your request, it'll be named as "Compact page list" or similar. I think there's no need to make it customizable.

@SoapyDaz. Welcome to the forums I can only guarantee that it works in 2.7x...Others have reported issues regarding PW 3+. I am waiting for a stable release of PW 3+ before I officially support the module for that version.

You can filter the notices with a hook before Page::render in /site/ready.php The file compiler notices are useful information so probably sensible to filter these notices only for non-superusers. $this->addHookBefore('Page::render', function($event) { $user = $this->user; if(!$user->isSuperuser()) { $notices = $this->notices; $notices->not("class=FileCompiler"); $notices->not("text~=Compiled file"); } });

Internet too slow to answer fast^^ Also check out processwire.com/api/ref

I have tried to improve the page list but I have to admit it's close to perfect as it is (at least for me). I see that this tweak could save some space but I'll wait until other page list related needs arise.

I'm so confused. Today it just started working. I didn't even do anything. Maybe opcache related? Even tested on different PW2 and PW3 sites. HI @adrian and @horst. I tried Tracy debugger and here is what it shows (see attachment) It also confirmed that I was editing the correct php.ini file. Thank you both for your help. I'm hoping it won't happen again

In addition to @horst's comments, in case you don't know, you can find out which php.ini file is being used from phpinfo() - if you have Tracy installed, turn on the PHP Info panel. Otherwise you can get this info from php -i|more in your terminal. Sorry if this is already basic knowledge for you!

Moar updates: Finished working on named types for parameters, which was the base param-type before ({name:type}). As you can see below, we're testing with {fileext:ext} which converts to the regex format for FastRoute to handle: Request URI: string(12) "AboutUs.html" Matched Jumplink Object: object(stdClass)#5 (4) { ["from"]=> string(113) "{page}.{fileext:aspx|asp|cfm|cgi|fcgi|dll|html|htm|shtml|shtm|jhtml|phtml|xhtm|xhtml|rbml|jspx|jsp|phps|php4|php}" ["to"]=> string(7) "{page}/" ["deepClean"]=> bool(true) ["origFrom"]=> string(20) "{page}.{fileext:ext}" } Captured Parameters: array(2) { ["page"]=> string(7) "AboutUs" ["fileext"]=> string(4) "html" } Parameter 'page' cleaned (deep = yes) from 'AboutUs' to 'about-us' Compiled Destination: string(9) "about-us/" Also notice the deepClean property of the Jumplink object: Instead of setting the old Enhanced Wildcard Cleaning in settings, this is now done on a per-jumplink basis (defaults to false). Going to start working on aliasing (aka old smart wildcards) now. Aliases will convert, for example, {id} to {id:\d+}.

Surprising myself, I have figured out how to hook into Page::addable. class MemberBranchAddable extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Member Branch Addable', 'version' => 3, 'summary' => 'Grant addable access to users on their member page', 'singular' => true, 'autoload' => true, ); } /** * Attach hook to Page::addable * */ public function init() { $this->addHookAfter("Page::addable", $this, 'addable'); } /** * Page::addable hook * * Add children permission is granted based on edit. * If they have edit access, then they can also add children, * but only apply this if the $page->template = 'member' * */ public function addable(HookEvent $event) { $page = $event->object; // If page template is $singular continue // That $singular should come from the // configuration if ($page->template->name == 'member') { // If page is editable and generally can have children, then allow addable if ($page->editable() && !$page->template->noChildren) { $event->return = true; } else { $event->return = false; } } } Which takes care of: And removes the requirement to manually edit wire/modules/PagePermissions.module

Small update from my side: I'm busy testing all of this out in a simple PHP script that imports FastRoute - so far, so good! For the purposes of better understanding and correct approach, I'd like to also change the mapping collection syntax from: {variable_name|collection_name} to: {collection_name(variable_name)} I did want to use square parenthises, but I'd like to try and not conflict with FastRoute's optional params. (Edit: Sorry, my mistake - FastRoute has nothing to do with destinations. I might switch back to pipes anyway... Not sure I like this format.) Thoughts? Update: Here's some testing output at the current stage: Request URI: string(25) "/page.php?id=2&category=1" Matched Jumplink Object: object(stdClass)#2 (2) { ["from"]=> string(47) "/page.php?id={page:\d+}&category={category:\d+}" ["to"]=> string(41) "/{categories(category)}/{page_ids(page)}/" } Captured Parameters: array(2) { ["page"]=> string(1) "2" ["category"]=> string(1) "1" } Identified Collection Item from page_ids: array(1) { [2]=> string(8) "about-us" } Identified Collection Item from categories: array(1) { [1]=> string(7) "company" } Compiled Destination: string(18) "/company/about-us/"

Have a look at the sql_mode setting of your MySQL server. This looks like ONLY_FULL_GROUP_BY is enabled.

Thanks arjen. I was thinking that it should definitely be possible (and I feel like I've done this type of sort before without any problems). 1. PW 3.0.28 (just upgraded it to see if that would fix the issue) 2. This particular one is a single Page field, though I have also tried it with a multi-page field (should that work? i.e. pagefield.first.title?) 3. Just tried that. Didn't work I also set the fields to auto-join.

Hi MichaPau and welcome to the forums. To change the password requirements go here: /setup/field/edit?id=3 You can access this via Setup > Fields, then under Filters, select built in fields and then edit the pass field. If you are running a recent version of PW 3 or 2.8 you will see these options: Back to your more general question, the ProcessWire Info panel of TracyDebugger (http://modules.processwire.com/modules/tracy-debugger/) will tell you the "Process" of the current page - see the "Process: ProcessUser" entry on the sixth row. That tells you that the User editing page is using the ProcessUser.module at /wire/modules/Process/ProcessUser/ProcessUser.module

This is my most ambitious PW site yet: http://vroom.pt It's an auto ad portal specially designed towards professional dealers. Some highlights you can't really see just browsing the website: Custom CMS for dealers (screenshot); Auto generated, customizable website for each dealer (examples here and here); The dealer can choose between a dark or light theme, then set a tone color; More themes will be added in the future with completely different designs. Optimized search algorithm to keep speed reasonable even when searching through thousands of results.

In my experience Wire Mail SMTP works better too. And here is an observation in general: If you are sending emails via PHP, I would highly recommend using SMTP methods where possible as every single email provider is cracking down on spammers to the point where messages that are not sent using a real MTA (real SMTP server) are having much harder time to comply. There are hundreds of parameters that are tested against and if you email does not conform to the ever growing technical specification (not just the message and envelope itself but also the path with all IPs involved) it simply goes into junk or lately even worse - gets rejected or sent to dev>null What would be wise here from the email module developers side would be to actually build some sort of a queue mechanism where connection timeouts/rejections are caught and the admin can be either notified via a 3rd party messaging or at least logged/saved for a redelivery option later on. For example if issue gets resolved with some IP blacklist situation or whatnot. Cloud based delivery solutions (eg Mandrill etc.) are starting to look more appealing.. my 2c

I haven't tried your module yet but FYI AdminOnSteroids has such feature, and it works with images too:

Nice one @heldercervantes. Looks like a good candidate for a case study write-up

Hi everybody, I'd like to share with you another new module. It helps you to manage user ratings for pages in a very simple way. You can add a user rating to a certain page with a line of code: $page->ratings->add(4) If the user is logged in, the module remembers which page the user has rated for. For non-logged-in visitors, the module stores the pages, the user has rated, in the session. You can get a page's rating and its total amount of votes in a similar way: $page->ratings->average; // => 3.2 $page->ratings->count; // => 5 For more information about this module, please check out its GitHub repository. You can check out a working version of the module here: http://curium-cte.lightningpw.com Edit: The module is now available in the ProcessWire modules directory. Update: Ratings has been updated to version 1.1, including a new, simpler API accessor. As always - please comment for bugs or feature wishes. Thanks in advance, Marvin

Thanks again for the port to leaflet! I prefer OSM over google maps and have been using it for quite some time. Leaflet is very powerful and opens up many possibilities. I forked Mats' module and added support for leaflet-providers so we can choose different map tile providers (see my post here). It is still a work in progress but seems stable. Once it is ready for production I'll make a pull request. Mats, do you think we should use leaflet-providers as standard or offer the user a choice whether they want to use it or not? Next up I will add an icon field and support for Leaflet.awesome-markers.