evan

Probably the easiest way to add existing images and variations to PW pages would be via the API – take a look at the PageImage class docs: <?php namespace ProcessWire; // Bootstrap ProcessWire: https://processwire.com/docs/front-end/include/ include './index.php'; $results = $pages->find('id=1'); // Your page query $myImage = '/myImage.jpg'; // The image foreach ($results as $result) { // Add initial image $result->of(false); $result->imageField->add($myImage); $result->save(); // Retrieve added image, add description $lastImage = $result->imageField->last(); $lastImage->description = "My description"; // Create variation of last image $variation = $lastImage->size(500, 500); $result->imageField->add($variation); // Add additional variations here, and format conversion $result->save(); } You'll need to augment this code to accommodate an existing list of images, or multiple images per page, to match against the PW pages. WebP (or any image format conversions, it seems) are not natively supported by PW, but it looks like some folks have figured out some solutions (inline, and more integrated) :

I figured this out, after running into this issue myself and digging into the FieldtypeTable class...definitely not intuitive though. Ideally a title or label property or method would just be exposed here. $field = $fields->get('table_field'); // Field $columnName = 'column'; // Column name in table $optionValue = 'my_option'; // Option value $optionTitle = $field->type->getSelectColumnOptions($field, $columnName)[$optionValue]; // Returns array of value => label echo $optionTitle;

What's your reason for wanting to do this? The solution will depend on your desired outcome: You want the assets to be virtually served from a subdomain (files on the same server). You could accomplish this with a symlink, i.e. creating a virtual host entry and path for your subdomain, and placing a symlink to the your_primary_domain/site/assets/files/ there. You want the assets to be served from a subdomain on a different server. Not sure how this would be accomplished. If the ProCache module's CDN integration is any indication, I'm guessing you'd need to find a way to reliably mirror the file structure of /site/assets/files/ on the subdomain's server, and modify all your asset URL requests in the templates to point to that subdomain. As a side note, I wouldn't categorize PHP templates as assets, since they're processed server-side and not URL-accessible, unless you meant something else.

Hey Sam, Welcome! It's definitely possible to build something like that. There's a few reasons why you didn't find an exact module for what you're trying to do. ProcessWire is more of a development framework and toolset than a plug-and-play CMS. It provides you easy access to a relational database, user and session management, querying, and front-end rendering through its API. As that's the case, much of what you want to do – create product records with categories and tagging, and query those records with those fields – can be done pretty easily with native PW functionality. A skeletal walk-through of how you might do this: Create a Product template in the admin. Create the fields you'd like for the Product – probably a Title, Body, Categories, and Tags. The last two could either be hard-coded (as a Select – more rigid) or relational (as a Page Reference/PageArray, using other Pages as data – more flexible). Create Pages with the Product template, and populate the data. Create a Product front-end template, /site/templates/Product.php (file shares the same name as your admin template name), with code like this: <h1><?=$page->title?></h1> <div class="body"> <?=$p->body?> </div> <div class="categories"> <?php foreach ($page->categories as $c): ?> <?=$c->value?> <!-- This is assuming your Categories are a simple Option fieldtype, without titles. --> <?php endforeach ?> </div> <div class="tags"> <?php foreach ($page->tags as $c): ?> <?=$c->title?> <!-- This is assuming your Tags are a Page Reference fieldtype. --> <?php endforeach ?> </div> Edit your front-end home template, /site/templates/home.php, and list some of your Products, maybe like this: <ul> <!-- List pages with Product template, limit results to 10 --> <?php foreach ($pages->find('template=Product, limit=10') as $p): ?> <li> <a href="<?=$p->url?>"> <?=$p->title?> </a> </li> <?php endforeach ?> </ul> That'll get you started with displaying and querying Pages. You might want to take a look at this article to better understand how Templates, Fields, and Pages relate to each other. E-commerce is one of the less well-represented areas of ProcessWire, but is 100% doable. The main bits that don't exist out-of-box are a shopping cart, order management, and the checkout process, but could definitely be built using PW. The module Padloper has both a cart and checkout process. You could get something mostly self-contained like Stripe or Snipcart running within a PW install in short order. Whatever the case, E-commerce in PW, and in fact most systems, will require some development and figuring out. Hope that helps!

Super handy, thanks! I issued a pull request for more efficient query syntax, i.e. using prev() & next(). I have an install with 1700+ siblings and the admin clearly was getting bogged down. These changes fixed it.

I've run into this issue a few times...extremely frustrating, until you figure it out, of course After some snooping I determined it has to do with mod_pagespeed's elide_attributes flag, which removes default values, i.e. <select multiple="multiple"> becomes just <select multiple>. Unfortunately, Inputfield asmSelect's JS hooks onto select[multiple="multiple"], and thus skips those elements when the value isn't explicitly set. Long story short, remove elide_attributes from ModPagespeedEnableFilters in pagespeed.conf, restart your web server, and it should work.

Yep, you can. Again, Page Table fields return a normal PageArray, so you can manipulate them as such. You'd need to iterate over the Page Table field on the pages that have that field, i.e.: $query = "My string"; $results = $pages->find('template=page_with_content_block'); $content_block_results = new PageArray(); foreach ($page_results as $p) { // Find pages with content block field if ($p->page_table_test->find('body*="'.$query.'"')->count() > 0) { // Check if content blocks contain query $content_block_results->add($p); // Add to results } else continue; } // Render $content_block_results or combine with other results

Your approach is slightly off – remember that the items in a Page Table field are actually pages. There's a few different ways you could do this, but here's how I've done it in the past, assuming the content blocks are children of the page: // Query normal pages $query = $sanitizer->text($input->get->query); $results = $pages->find('template!=content_block, title|body*="'.$query.'"'); // Query content blocks $content_blocks_query = [ 'template=content_block', // Template 'title|body*="'.$query.'"' // Fields ]; // Find parent pages of content blocks $content_block_results = new PageArray(); foreach ($pages->find( implode(', ', $content_blocks) ) as $p) { $content_block_results->add($p->parent); } // Combine results $results->import($content_block_results); // Render $results If you're talking about Page Table Extended's admin-side rendered HTML, it actually works independently of the normal templates. Take a look at the PageTable Render Layout Options, you can specify CSS and template files there.

Sounds pretty similar to what someone else was asking. You can do something like this with Page Table or Page Table Extended:

You can make content blocks with Page Table or Page Table Extended, to display on any page. Create a Page Table field. Create templates for each of your content blocks, assigning the necessary fields (PHP files not necessary for these). Configure your Page Table field to use those content block templates. Assign Page Table field to your front-end template (template.php). In template.php, iterate over the Page Table field, and use PHP switch() to display different HTML and field data based on the content block name. If you want to get fancy, configure Page Table Extended to display rendered HTML on the admin side (Display Output Options).

You shouldn't need to touch index.php, unless you're doing something really unorthodox. Are you logged into the PW admin (assuming that resolves)? Verbose errors will be supressed if not. You also might check /site/assets/logs/ for an error log, or your server logs. Hope that helps! Welcome.

Good idea, but 3.0.66 still produces the same error. Seems like this affects Page Table in particular, so I've moved the discussion to ProFields forum (protected content): https://processwire.com/talk/topic/14244-error-uncaught-error-class-languagespagefieldvalue-not-found-in-fieldtypetablefieldtypetablemodule1953/#comment-147372

Hello, Has anyone else had issues with multi-lingual fields within Page Tables? I tried using a Text (Multi-Language) field, and it craps out on me on page save when trying to add an item: Error: Class 'LanguagesPageFieldValue' not found (line 1632 of [..]/site/modules/FieldtypeTable/FieldtypeTable.module) Running PW 3.0.62. Thanks!

For some reason the script doesn't find anything for me when checking for the correct Fieldtype. $field->type instanceof FieldtypeImage and $field->type instanceof FieldtypeFile never returns true for any of my Image fields, but $field->type->name == "FieldtypeImage" does. My working validation loop looks like this: $valid = array(); foreach($page->template->fieldgroup as $field) { foreach($page->get($field->name) as $file) { $valid[] = $file->basename; if($field->type->name == "FieldtypeImage") { foreach($file->getVariations() as $f) { $valid[] = $f->basename; } } } } I'm running PW 3.0.42, PHP v5.5.27.

I had the same issue in PW 2.7.2 and Lister 0.2.4. I tried swapping the Process of the Search page (/processwire/page/search/) , under Admin > Pages in the Tree to ProcessPageLister, and that seemed to fix it. You'll have to unlock the page to change the Process, and make sure the users' role has permission to use page-lister. Not sure why this happens. This is on an install that I've been upgrading since 2.5.3. It works without issue, and using ProcessPageSearch, on my newer, clean install of 3.0.42. Update: looks like it breaks the normal page search, so obviously not a good fix.