evan

Something I've adopted for my PW sites is putting environment-specific DB credentials and configuration in a separate file, /site/config.local.php: /** * Installer: Database Configuration * */ $config->dbHost = '127.0.0.1'; $config->dbName = 'db'; $config->dbUser = 'default'; $config->dbPass = 'default'; $config->dbPort = '3306'; /** * Installer: HTTP Hosts Whitelist * */ $config->httpHosts = array( 'my-local-domain.test'); And then including that file into /site/config.php: /*** INSTALLER CONFIG ********************************************************************/ // DB Config, Hosts Whitelist include dirname(__FILE__) . '/config.local.php'; I find this makes it easier to push changes when using version control (i.e. git) across different environments, and keep the credentials and other sensitive information excluded from the repo. On some managed hosts like Cloudways, you can pull and push DB changes from staging to/from production applications, as well as branch changes from git. Obviously this doesn't help when you make DB changes locally, though. Otherwise, I will either export/import the entire DB via the Database Backups module, or Pages Import/Export (under Admin > Modules, Core modules) depending on the kind of changes. After using Vercel and Netlify for static-based websites, it does make me wish there was a quicker way to push/pull DB changes, but perhaps that extra bit of friction is good so you don't inadvertently disrupt your production data. Definitely something I can improve in my own workflow! Managing local/remote image assets Occasionally I've added this code snippet to /site/ready.php, that allows for your local installation to pull down the asset from prod, which can save you some time. I'm also generally curious to know more about other folks' deployment strategies – could be a potentially useful thing to collect and make more visible in the PW docs, too.

Hi everyone – very infrequent poster here, and also a long-time PW user in my web development career, for which I am deeply appreciative. Like @Ex-user, I have a lot of intense skepticism about AI, not only because of the environmental consequences being referred to, but also the invisibilized human costs in training these algorithms, as well as the risk of impacting critical thinking skills. I bristle at the way it's being coercively marketed as the inevitable answer to every human problem. That being said, I, like everyone else, recognize I have a career because of the many visible and hidden costs of digital technologies. That neither means I am "pure" or exempt from the hidden costs, nor does it mean I accept everything without pause. I think we all are attempting to make the best decisions for ourselves and consideration for others, and this may be expressed in differing ways when it comes to AI usage. For me, the primary issue with using AI is the matter of trust and accountability – what person is bearing responsibility for the work it produces or choices it makes? If PW's codebase adopts any changes suggested by AI, my hope would be that it undergoes the same level of testing and scrutiny as any other code revision, and it seems like Ryan is doing just that. If I have any say as a PW user in how AI is adopted into the main codebase, my hope would be that it's a transparent, auditable process, and (somewhat idealistically, from my own personal, ethical position) continues to be opt-in.

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!