Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


gebeer last won the day on February 27

gebeer had the most liked content!

1 Follower

Profile Information

  • Gender
  • Location

Recent Profile Visitors

11,641 profile views

gebeer's Achievements

Hero Member

Hero Member (6/6)




Community Answers

  1. @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
  2. 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.
  3. Same behaviour here wirh PW 3.0.214 on PHP8.1
  4. 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.
  5. 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?
  6. 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
  7. Great idea. This is the most flexible way of handling categories. Go for it 🙂
  8. 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.
  9. Hi @teppo after checking your module code more carefully I found the already hookable methods ___getPageIndex and ___getFieldIndex. So please ignore my post above 🙂
  10. 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.
  11. 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.
  12. @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?
  13. 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?
  • Create New...