gebeer

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

Great idea. This is the most flexible way of handling categories. Go for it 🙂

I found https://github.com/earldouglas/codedown which can be used to extract all code snippets programmatically from the markdown files. With Jekyll, code from gists can be embedded into markdown files: https://gist.github.com/benbalter/5555251 Couldn't find anything for 11ty, though. I browsed only through a few of the md files on https://github.com/webmanufaktur/processwire-recipes/tree/master/src/recipes and they looked quite uniform already. Haven't checked all of them, though. Are these all that exist? Everybody should have moved to PW 3.x already. How would you identify 2.x snippets? Most of the code from 2.x still works in 3.x. So I don't think that this destinction is necessary. As for the default standard. https://github.com/webmanufaktur/processwire-recipes/blob/master/src/pages/submit-recipe.md already is a good starting point. I don't think we need categories in addition to tags. Categorization can be done through tags in a flexible manner. Couldn't we also use tags for that, like "init", "ready", "hook"? EDIT: I just did that and made a PR.

Hi @teppo after checking your module code more carefully I found the already hookable methods ___getPageIndex and ___getFieldIndex. So please ignore my post above 🙂

Oh great, thank you. So this means that Repeater Matrix fields are supported out of the box or do you need to tell the module how to process them? If there is custom code/hooks involved would you mind sharing a snippet? 🙂 EDIT: I just saw that Indexer::getFieldIndex has logic for repeater fieldtypes. So no need for a snippet.

Hi @teppo and thank you for this module. I am evaluating Whether we can use this for a bigger project. The project makes heavy use of Repeater Matrix fields. And those seem not to be supported atm. Could you make the Indexer::indexPage method hookable? That way we could implement our own code for non supported fieldtypes. That would be awesome.

@wbmnfktr Thank you so much for breathing life back into this project. Website already looks awesome. I have an idea/suggestion: it would be great if all the code snippets could easily be integrated and used in our IDE. With the current way of how they are stored on GH I wouldn't how this could be achieved. There is a vscode extension that lets you use gists as code snippets. So if the actual code snippets were organized in gists it would be possible to use those from within the IDE. Maybe there is an automated way of storing all snippets as gists from within your build process?

That would be perfect! ATM there are too many steps involved when tagging uploaded media. Doing the tagging based on the "folder" would be a big improvement. I agree this should be separate from the media types. Maybe something like "uncategorized" This should definitely be possible. So media that has multiple categories would appear in multiple virtual folders. Yes and no 🙂 The inbuilt image/file tags could be used in the background to store the tags. But for editing I would prefer if I did not have to edit an image before I can input tags. It would be cleaner and faster for editors if they can just edit tags directly without having to go the extra step to edit the image. So the tags field would have to live on the MM page that holds the media. Does that make sense? Also there should be a way how we can pre-define available categories. Just like we can pre-define available tags for aan image/file field. The simpler the better 🙂 Almost all of my clients are overwhelmed by PW Lister filters. Even with predefined filter profiles it is hard for non-techy people to understand the concept and what they see in the dropdown selects. I think this is a very tough one to tackle. If you have just one search input like in WP, you get back results that you where not looking for because the search is too broad. Maybe a combination of a text input that searches for file names and one select dropdown that determines the category you want to search in could work? Totally agree. It could be a configurable option whether to include files from subfolders in the view or not. Great suggestions. For the time being a config option for icon size would be helpful. Or do the Preview maximum width/height settings already have an effect on those icons?

Thank you Moritz!