Leaderboard

Hey @gebeer nothing dangerous ? I don't think that anybody except me was using this, but it's a breaking change... Anybody not using it can safely update. Before: {$img->maxSize(500,500)->murl} After: {$img->maxSize(500,500)->webp->url|vurl} This adds a version-url string for cache busting which is especially great when changing image focus point as then often the image url does not change (its still ...500x500...) but the image should get reloaded by the browser. This simple latte filter ensures that and the old ->murl had problems with webp so I changed it ?

@fruid Use custom page classes. In site/classes: <?php namespace ProcessWire; class UserPage extends User { public function getMessages(): PageArray { return wire()->pages->find('template=message, receiver=' . $this->id); } } Be sure to enable it in site/config.php: $config->usePageClasses = true;

Nope, 18 was a brand new version (after your bug report). Sorry, I missed that line - I did get the one (and one other) from your initial report, but that was one I missed. The latest should hopefully be OK now.

I'm experiencing this in production, not with Laravel. It appears to happen when the path has an empty segment, e.g. https://gregorlove.com//xmlrpc.php?rsd This isn't a valid URL on my site, I know it's just someone scanning for vulnerabilities, but I saw this error in the Tracy logs: Warning: Undefined array key "path" in /site/assets/cache/FileCompiler/site/modules/TracyDebugger/TracyDebugger.module.php on line 2865 Deprecated: explode(): Passing null to parameter #2 ($string) of type string is deprecated in /site/assets/cache/FileCompiler/site/modules/TracyDebugger/TracyDebugger.module.php on line 2865 ProcessWire: 3.0.210 PHP: 8.1.27 TracyDebugger: 4.25.17 Update: The issue appears to be that `REQUEST_URI` in this instance is `//xmlrpc.php?rsd`. Running parse_url() on that does not return a path segment because it parses `xmlrpc.php` as the host and `?rsd` as the query. The following explode() line expects that path. I think there needs to be some more sanitization before using the result of that parse_url().

Yes. I actually tie this in with custom page classes, because often the page class matches a structured content type. When I am building a site that is using a repeater block system, there are three 'tracks' of data that get pulled in: structured data, page data and presentation data. Usually structured data is a php file that outputs json. Page data is a php file that does whatever calculations I need for a content block and passes a special latte variable into the latte variable array. Presentation data ties together the structured data and bring in a special computed variable from the latte variables I have set. This way the structured data logic, data cleaning prep logic and presentation logic remain separate.

Hello all, I was running into an issue where a particular repeater matrix structure failed to index properly. In a structure like this: Template Repeater Matrix Field Matrix Type Page Field Page Id Name Title Headline Body Summary So where you have a page template with 'zones' that allow you to place a matrix type that acts like a block with a page selection field in it to insert a piece of content, that deeper piece of content was not getting properly indexed no matter what indexed fields you set in place. In SearchEngine/lib/Index.php within the function __getFieldIndex there is a section that overrides the $indexed_fields array with a hard-coded array. In the version below I have commented it out and restored the $indexed_fields array and the referenced child page content for Repeater Matrix Types now indexes properly: /** * Get index for a single field * * @param \ProcessWire\Field $field * @param \ProcessWire\WireData $object * @param array $indexed_fields * @param string $prefix * @param array $args * @return array */ protected function ___getFieldIndex(\ProcessWire\Field $field, \ProcessWire\WireData $object, array $indexed_fields = [], string $prefix = '', array $args = []): array { $index = []; if ($this->isRepeatableField($field)) { $index = $this->getRepeatableIndexValue($object, $field, $indexed_fields, $prefix); } else if ($field->type->className() == 'FieldtypeFieldsetPage') { $index = $this->getPageIndex( $this->getUnformattedFieldValue($object, $field->name), $indexed_fields, $prefix . $field->name . '.', $args ); } else if ($field->type instanceof \ProcessWire\FieldtypePage) { // Note: unlike with FieldtypeFieldsetPage above, here we want to check for both FieldtypePage // AND any class that might potentially extend it, which is why we're using instanceof. /** $index = $this->getPageReferenceIndexValue($object, $field, [ 'id', 'name', 'title', ], $prefix); */ $index = $this->getPageReferenceIndexValue($object, $field, $indexed_fields, $prefix); } else { $index_value = $this->getIndexValue($object, $field, $indexed_fields); $index[$prefix . $field->name] = $index_value->getValue(); foreach ($index_value->getMeta(true) as $meta_key => $meta_value) { $meta_value = explode(':', $meta_value); $index[self::META_PREFIX . $meta_key . '.' . $field->name . '.' . array_shift($meta_value) . ':'] = implode(':', $meta_value); } } return array_filter($index); } I don't know if this was set in place for performance reasons, but if you are using a page template structure with page fields you may have run into this problem where in some cases only the content titles is included in the search_index output.. This change does extend the indexing timeframe, but pages are indexed fully.

thank you, that is exactly what i searched for

So when you create another page (lets call it homepage_new) with the same template as your homepage template, it works and the body of homepage_new is editable in frontend?