gebeer

I think this is a great idea and would love to see it implemented. Of course you could achieve this with partials, if statements etc. But your proposal would make things much cleaner imo. Great resource. Thank you for putting this together.

There's

I made a proof of concept how this could look like: https://codepen.io/gebeer/live/qBJdJjd If you want to adapt that, we can go on from there.

The search is working now 🙂 Some thoughts: For someone who doesn't really know what they are searching for, it would be good to have a tag list (either complete or a subset) on the search page. By clicking one ore more tags, all relevant recipes should be listed as results. a tag list with the same functionality could also be implemented on the main recipes page (top or side)

Very interesting. I was looking into vicuna as well. Haven't installed it yet due to hardware "shortages". But these open source projects are very promising. Only thing they would need is some more specific trainig for programming, PHP, ProcessWire before they can be useful for that purpose. And that training stuff is the most time consuming. But generally I would prefer using an AI installed in my local network and specialized in the tasks I need to solve rather then those all purpose models that are publicly available for the masses...

@gornycreative guess you meant to post this at ?

Thanks for the updates and happy easter! When I click on the search icon I get redirected to https://processwire.recipes/topic/search/. Some if I type /search in the URL diractly. Something going wrong with the routing there, I guess

Additional info: with above solution, chinese characters are preserved as UTF8 in page names. But all other UTF8 characters in other languages do not get translated with pageNameTranslate like they would if the site didn't have $config->pageNameCharset = 'UTF8'; That is undesirable because for example, german umlauts now get translated from ä to a instead of ae. If setting $config->pageNameCharset = 'UTF8' is active, the pageNameTranslate sanitizer ignores the character map, that we can usually set in the module settings for InputfieldPageName. Actually, that editable character map is no longer available when $config->pageNameCharset = 'UTF8'. To circumvent this issue, I manually replace all characters before passing them to sanitizer pageNameTranslate I wrote a function that takes the default character map for replacements from InputfieldPageName::$defaultReplacements, adds custom characters and then performs string replacements based on the character map: /** * replaces characters in a string with characters from a custom character map * needed because Sanitizer::pageNameTranslate() doesn't take into account the character map defined in InputfieldPageName * because the site uses $config->pageNameCharset = 'UTF8'; * used in the Pages::saveReady hook in ready.php * * @param string $string * @return string */ public function replaceCustomCharacters($string) { // take default character map from InputfieldPageName class $defaultChars = InputfieldPageName::$defaultReplacements; // add additional characters $allChars = array_merge($defaultChars, [ 'ä' => 'ae', 'ö' => 'oe', 'ü' => 'ue', 'ß' => 'ss', ]); // replace all characters from map $allChars in $string $string = str_replace(array_keys($allChars), array_values($allChars), mb_strtolower($string)); return $string; } My final saveReady hook now looks like this: /** * 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; // exclude admin pages if($page->rootParent->id === 2) return; // exculde pages under admin tree (e.g. media manager pages) $languages = $event->wire('languages'); /** @var Sanitizer $sanitizer */ $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(wire('site')->replaceCustomCharacters($translatedTitle)); } $page->setLanguageValue($language, 'name', $pageName); } }); Note that my replacement function lives in a custom Site module that is made available to the API as wire('site'). All in all there is a lot to consider with UTF8 page names activated. I wish PW would make life easier here. Just the other day when I played around with GPT-4 and asked it how we could solve that problem, it started to halluzinate and proposed that the only thing I had to do was setting utf8PageNames property per language like in this dummy code: $lang = $languages->get('cn); $lang->utf8PageNames = true; $lang->save(); In reality the Language object does not have such a property. But I think, this would be a great enhancement and would allow setting page name behaviour based on each language and not globally only, like it is now. Will open a feature request.

After all the research I have done on how we can train chatGPT specifically for ProcessWIre, I came to realize that it knows already knows PW and its API quite well. I experimented with prompts to make GPT-4 into a PW specialist. This is what I came up with and what seems to work really well: This primes GPT-4 and brings really good results when asking further questions. This example shows that it knows a lot about the API in detail: Q: Are you aware of the ProcessPageClone class and its methods? Not bad at all 🙂 What I'm still having difficulties with is prompting copilot, tabnine or codeium to give me PW specific code. But thats a different story...

This is great news and highly appreciated. The module as is works great for the most parts. But to make it work with snipcart v3, it does need some adjustments. Other than that I have it running without major issues. Since I thought that it won't be continued, I did quite some changes to the code in my install. Might turn that into a fork. Maybe there's something you can make use of. EDIT: Oh, I just saw that I had already forked it. But needs some cleanup, I guess...

The status can be used as active toggle. But, as you said, this highly depends on the use case. I have several sites where a separate 'active' checkbox field is required because in PageLister (like Pages->Find) those pages should appear for user roles other than superuser and not be striked-through.

I can highly recommend using https://ddev.readthedocs.io/en/stable/ for local development. Instead of installing LAMP stack on the local machine's host, you get everything containerized. Big advantage is that you can run different projects in different environments and replicate the live server environment easily for each project. There's also a dedicated Thread for ProcessWire and ddev:

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.