gebeer

I solved it with this hook: /** * only use UTF-8 page names for defined languages */ $wire->addHookBefore('Pages::saveReady', function($event) { /** @var Page $page */ $page = $event->arguments(0); if($page->template->name == 'admin') return; $languages = $event->wire('languages'); $sanitizer = $event->wire('sanitizer'); $utf8Languages = ['cn']; // Add more languages as needed foreach ($languages as $language) { if ($language->isDefault()) continue; $langName = $language->name; $translatedTitle = $page->getLanguageValue($language, 'title'); if (in_array($langName, $utf8Languages)) { $pageName = $sanitizer->pageNameUTF8($translatedTitle); } else { $pageName = $sanitizer->pageNameTranslate($translatedTitle); } $page->setLanguageValue($language, 'name', $pageName); } });

You are making use of this for your deployment workflow with RockMigrations, right?

As a follow up, I dropped that plan after I read about chatGPT plugins, specifically the retrieval plugin and then watched This seems a better way to go. But, then again, after watching I realised what a big effort it is to initially collect the data before we can provide it to chatGPT via the retrieval plugin. Definitely not something that I would be up to on my own. But at least I learned something ? Apart from that, the more I read about the company openAI the more I realise that I don't want to support them. Being a proponent of the open source spirit, I'll better look deeper into really open projects like https://github.com/nomic-ai/gpt4all and see how I can get a fine tuned model for programming with PW. Like @gornycreative said earlier, I also think the future lies in more specialized models. Anyways, still a long way to go until we have chatPW ?

I'm also reusing generic fields in my templates with renamed labels. Keeps the DB cleaner. I use custom page classes, a great feature that was introduced in 3.0.152 to map those generic field names to more meaningful properties. This way I get intellisense in my editor and don't have to look up the mappings of generic field names to meaningful ones. Here's an example page class: <?php namespace ProcessWire; use RockMigrations\MagicPage; /** * Custom page class that provides properties/methods for pages with template glossary-item * * */ class GlossaryItemPage extends DefaultPage { use MagicPage; /** * holds the glossary term * * @var string $term */ public $term; public $hide; public $exclude; public $tooltip; public $meaning; public $description; // set custom properties in loaded public function loaded() { $this->set('term', $this->title); $this->set('hide', $this->checkbox); $this->set('exclude', $this->checkbox2); $this->set('tooltip', $this->text); $this->set('meaning', $this->text2); $this->set('description', $this->rte); } /** * Magic Page hook for clearing cache for terms from module Glossary * */ public function onSaved() { $this->wire->cache->delete(Glossary::CACHE_NAME); } } The property->fieldname mapping happens in the loaded() method. you can comment the property definitions so you get some meaningful info with code intellisense. In the template where I want to use pages with template glossary-item, I define the type for those pages to get intellisense: /** @var GlossaryItemPage $p */ <?= $p->term ?> Some notes on the page class code: The GlossaryItemPage extends DefaultPage. My DefaultPage class is a base class for all other page classes which holds generic methods that I want to have available in all page classes I'm using @bernhard's fabulous RockMigrations module which, apart from migrations, provides MagicPages. This makes it super easy to add commonly used hooks to your page classes. I have a Glossary module installed which handles migrations and logic for the glossary. In the migrations for that module I define the custom field labels in the template context: 'glossary-item' => [ 'fields' => [ 'title' => [ 'label' => 'Name of the Term', ], 'checkbox' => [ 'label' => 'Hide', ], 'checkbox2' => [ 'label' => 'Exclude this term from parsing', ], 'text' => [ 'label' => 'Text Shown in the CSS Tooltip', ], 'text2' => [ 'label' => 'Meaning', ], 'rte' => [ 'label' => 'Description of the Term', ] All in all this is a very structured approach. It surely takes some extra time to setup. But this pays back, especially for larger, more complex projects. It took me quite some time as PW developer to come to this kind of setup. I started out with very simple procedural code. I wish I had all these tools available when I started out developing with PW that we have now (page classes, migrations etc.) thanks to this great community. Everyone here has their own approach and workflow. So you will surely get some inspiration.

Thanks. I decided to use PHP Documentor https://www.phpdoc.org/ with a custom template that outputs to JSONL. It is in the making...

To follow up on that, I fed this into GPT-4: That was it's reply:

Some scary aspects indeed.. Good that some folks are trying to bring this to our attention. But it might be too late...

OpenAI are moving on pretty fast. Referring to my last post, there is a more up to date way of supplying training data to LLMs with instructions from https://platform.openai.com/docs/guides/fine-tuning I think we could use this to train the AI on the PW API. We'd need to provide a JSONL file with training data. The data should contain the usage descriptions and examples from the PW API docs. As far as I know the API docs are automatically generated with PHPDocumentor https://www.phpdoc.org/ I am looking for ways to convert the present HTML output from Documentor to JSONL files. Maybe output XML first with Documentor and then convert that. Or write a Documentor template that outputs JSONL directly. Just an idea, but should be doable. Is anyone here experienced wit PHP Documentor and can tell me whether this is possible?

I did some testing with HTML like <p>E-Mail: <a href="mailto:test@email.com">test@email.com</a></p> and it didn't catch the links. I think this is related to https://github.com/patman15/EmailObfuscation/blob/cfb7d7e50cf7ac47a6b40b054e4174275df7b68e/EmailObfuscation.module#L375 !empty($arr = ...) The $arr definition should be outside !empty(), I guess. Also you original mailto_pattern didn't catch the address until I removed self::fastpattern. Also mailto hrefs like this do not work: <a class="icon social ma" href="mailto:?subject==?UTF-8?B?RGllIFdlYnNpdGUgZGVyIFNQSUVMQkVSR0VSIE3DvGhsZSB3dXJkZSBkaXIgZW1wZm9obGVu?=&amp;body=https%3A%2F%2Fspielberger.ddev.site%2Fde%2Fimpressum%2F" title="Diese Seite per Email teilen"><span class="sr-only">Diese Seite per Email teilen</span></a> And yes, I think modifying the DOM while iterating can cause some issues. You might want to collect all relevant node instances in an array first and then iterate over that and do the replacement.

Building the sitemap for more than 500 URLs takes quite some time. That's why I noticed.

Hi @Mike Rockett I just discovered that the sitemap is always generated, no matter what cache settings. In https://github.com/mikerockett/markup-sitemap/blob/2db851e9bc3e7147879dced1bcfe515cd86562a8/MarkupSitemap.module.php#L269 the generation is done before checking for cache and returning cached output. I amended the method to read protected function getSitemap(string $rootPage): string { // Bail out early if debug mode is enabled, or if the // cache rules require a fresh Sitemap for this request. if ($this->requiresFreshSitemap()) { $sitemap = $this->buildNewSitemap($rootPage); return $sitemap; } // Cache settings $cacheTtl = $this->cache_ttl ?: 3600; $cacheKey = 'MarkupSitemap'; $cacheMethod = $this->cache_method ?: 'MarkupCache'; // Attempt to fetch sitemap from cache $cache = $cacheMethod == 'WireCache' ? $this->cache : $this->modules->MarkupCache; $output = $cache->get($cacheKey, $cacheTtl); // If output is empty, generate and cache new sitemap if (empty($output)) { header('X-Cached-Sitemap: no, next-request'); $sitemap = $this->buildNewSitemap($rootPage); $output = $sitemap; if ($cacheMethod == 'WireCache') { $cache->save($cacheKey, $output, $cacheTtl); } else { $cache->save($output); } return $output; } header('X-Cached-Sitemap: yes'); return $output; } This seems to be working fine.

Now that there is llamaindex https://gpt-index.readthedocs.io/en/latest/index.html with connector for github repo https://llamahub.ai/l/github_repo available, I thought it would be awesome to have a LLM that is specifically trained on PW. I thought I'd give it a try and asked GPT-4 for some guidance on how to create an index and then setup training and so on. Here's what I asked for And that was the answer Disappointing. This answer proves that even GPT-4 has only data until Sept. 21 available. At that time llamaindex was not public yet. I'm not into python at all. So I would have a hard time when trying to setup indexing of the PW github repo and then training a LLM on that index. I'd love to see how this would work out. But GPT-3 and 4 are already quite good at understanding PW, it seems. I installed https://marketplace.visualstudio.com/items?itemName=Rubberduck.rubberduck-vscode in vscodium. So I don't have to switch to the browser when asking GPT. Pretty neat tool.

Just wanted to install Copilot on https://vscodium.com/. Unfortunately not possible atm. And don't think it will be possible anytime in the future. Seems like MS is locking open source projects out. Anyways, I opted for https://codeium.com/ and will give this a go. Had https://www.tabnine.com/ installed for almost 1 month. But it was no great help IMHO. Especially when it comes to PW specific stuff.

I didn't want to say that this is a limitation. Actually it is an enhancement to have this functionality at runtime ? Just wanted to make sure that I'm on the right track with defining fieldsets and their fields in my migrations. Will definitely give the runtime approach a try. Thank you.

@bernhard At https://github.com/baumrock/RockMigrations#working-with-fieldsets you have e nice description on how to work with fieldsets. This seems to be limited to adding fields to fieldsets at runtime. Is there a way how we can define a migration that puts fields inside a fieldset in template context? Something like 'content-page' => [ 'tags' => 'content', 'fields' => [ 'title' => [ 'label' => 'Page Title', ], 'text' => [ 'label' => 'Subtitle', ], 'content_blocks' => [], 'tab' => [], // this adds the fieldsettab open and close 'fieldname' => [] // how to add this one to the tab fieldset ], It works fine with with $rm->addFieldToTemplate('fieldname', 'content-page' , 'tab', 'tab_END'). Just wondering if it is possible to do this inside the fields array in my example above.

It's the little things sometimes ?

Maybe try and remove the textformatter from the textfield before uninstalling the module.

My question was kind of stupid anyways since you wrote that the videos appear in the cache... As for the install/uninstall problem: Did you uninstall it through the module's edit screen before deleting the files?

Did you add the textformatter to the field where the video content is stored in? I have the module running latest version and everything is fine.. PW 3.0.214, module version 2.0.2 PHP 8.0.12

@horst after a PHP upgrade to 8.2 we get these deprecation warnings: PHP Deprecated: Creation of dynamic property ImageManipulator02::$originalImage is deprecated in ImageManipulator02.class.php:215 PHP Deprecated: Creation of dynamic property ImageManipulator02::$configOptions1 is deprecated in ImageManipulator02.class.php:265 PHP Deprecated: Creation of dynamic property ImageManipulator02::$configOptions2 is deprecated in ImageManipulator02.class.php:267 PHP Deprecated: Creation of dynamic property ImageManipulator02::$dibIsLoaded is deprecated in ImageManipulator02.class.php:839 PHP Deprecated: Creation of dynamic property ImageManipulator02::$iptcRaw is deprecated in ImageManipulator02.class.php:362

I just tried your fork and the replacement is not working for me. The preg_match_all inside the parseNode method doesn't pick up email addresses at all. I dumped $node->nodeValue and even if valid email addresses are in there, they don't get detected by preg_match_all and matches[0] always is an empty array. Also, if email adresses are wrapped inside an a tag with href="mailto:..." they don't even appear in $node->nodeValue and therefore do not get parsed.

Same behaviour here wirh PW 3.0.214 on PHP8.1

Nice. Does the module offer a UI under the admin tree? I'm asking because there are naming conventions for PW modules. And the prefix "Process" is usually reserved for modules that have a page associated under the admin tree. Like ProcessPageLister etc. You might want to consider renaming your module before submitting it to the directory.

Hi, I have a multilang project that requires UTF8 page names and slugs mainly for chinese language. Referring to the documentation at https://processwire.com/blog/posts/page-name-charset-utf8/ and this post it seems that we can use $config->pageNameWhitelist="" to allow all characters. Or, to allow only certain characters, we can use a list of those e.g. $config->pageNameWhitelist="æåäßöüđжхцчшщюяàáâèéëêě...". In my usecase I want to allow all traditional chinese characters, but disallow german Umlauts, so that page names in chinese are using the UTF8 characters, but a german page name like "über-uns" gets converted to "ueber-uns". With the avalable config settings, I don't see how I can accomplish that other than putting all traditinal chinese characters into the $config->pageNameWhitelist which is not feasable. What I would need is a blacklist. Sanitizer.php uses a blacklist: https://github.com/processwire/processwire/blob/6ff498f503db118d5b6c190b35bd937b38b80a77/wire/core/Sanitizer.php#L844 But I can't add to that. A config setting like $config->pageNameBlacklist would be great. Since we don't have that I need to work around the problem. I'm thinking of a Page::saveReady hook. That checks for german Umlauts and than translates those to the required values. Does anyone have a better idea?

A search/filter via Vue or alpine js with browser history would surely help here. And/or showing the recipes in a modal could also help for quickly navigating between recipes. I'd opt for PR to that same recipe. There's no need to keep around old outdated versions if improved ones exist. I think we can discard recipes for 2.x. But versioning for 3.x would be good because for some API methods we need a min version