Jump to content

gebeer

Members
  • Posts

    1,386
  • Joined

  • Last visited

  • Days Won

    39

Everything posted by gebeer

  1. 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.
  2. Same behaviour here wirh PW 3.0.214 on PHP8.1
  3. 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.
  4. 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?
  5. 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
  6. Great idea. This is the most flexible way of handling categories. Go for it 🙂
  7. 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.
  8. Hi @teppo after checking your module code more carefully I found the already hookable methods ___getPageIndex and ___getFieldIndex. So please ignore my post above 🙂
  9. 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.
  10. 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.
  11. @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?
  12. 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?
  13. Same experience with our clients. They are coming from TYPO3 and are used to organize media in folders. Trying to explain that the MM approach is much more flexible. But they'd still love to have their folders back. Technically this would mean that there is some kind of default categorisation apart from media type. I think using tags would be the best and most flexible method.
  14. If it is a field called "type" in store_template, it should be as simple as // for text field or select options $pages->get("template=store_template,equipment_ref.title='Equipment2, type="Type1"'); // for page ref field $pages->get("template=store_template,equipment_ref.title='Equipment2, type.title="Type1"'); Even if you have a page reference field with multiple entries, this selector will return a page as long as one of the entries has title "Type1".
  15. Where is the condition Type1 in your structure?
  16. Behind the scenes entries in a PageTable field are just regular pages in a regular PageArray. Lets say you have a field "pagetable" and it is configured to use template "blog-post" for items. You can create a new page with new items in the pagetable field like this: // create page that holds pagetable items $p = new Page(); $p->template = 'basic-page'; $p->parent = '/foo/'; $p->title = "Bar"; $p->save(); // get parent id for pagetable items from field config $parentID = $p->getField('pagetable')->parent_id; // create item page for field pagetable $item = new Page(); $item->template = 'blog-post'; $item->parent = $parentID; $item->title = "Item Foo"; $item->save(); // add item page to pagetable field $p->pagetable->add($item); $p->save('pagetable'); Since the value of $p->pagetable is a PageArray, you can find and manipulate the pagetable items with methods from Pages, PageArray and WireArray. To remove a specific item: $item = $p->pagetable->get('title="Item Foo"'); $p->of(false); $p->pagetable->remove($item); $p->save('pagetable'); You can also use WireArray manipulation methods insertBefore(), insertAfter(), append(), prepend() to add items in a specific order.
  17. Unfortunately not anymore since 8.0. The docs say But thanks for looking into it 🙂
  18. Glad you sorted it out 🙂 My example was in a mudule's config inputfields context. That is why $inputfields was null in your context. Are you still using Hannacode? You don't really need it.
  19. I think what you are looking for is an https://processwire.com/api/ref/inputfield-markup/ inside your Block Ordering Tab. You can use that to output the markup that is being supplied by your Hannacode. And you don't even need that Hannacode. Because your development template ordering lives on a single page that doesn't change in different contexts. So you can produce the markup for InputfieldMarkup from that page id. For InputfieldMarkup you can set the property markupFunktion to a closure that outputs your block order. Something like /** @var InputfieldMarkup $f */ $f = $this->wire->modules->get('InputfieldMarkup'); $f->set('label', 'Development Template Ordering Status'); $f->set('markupFunction', function () { $markup = ''; foreach(wire('pages')->get(yourid)->get('block_order_field') as $block) { $markup .= "{$block->title}<br>"; } return $markup; }); $inputfields->add($f); This will output something like
  20. Yeah, I guess that is why. My understanding is that every FieldsetPage field value is stored on page in the Admin pagetree behind the scenes. And by default those are not accessible for guest users.
  21. Have you tried adding include=all to your children selector?
  22. In your selector the Repater Matrix Type is missing. Your "items" repeater matrix field needs to have some named "types" setup in the field configuration screen. The textfield is inside that type. If repeater matrix field "items" with type "image_text" has a field "textfield", your selector would look like: content_sections.items.type=image_text To get all pages that have items of type image_text you can use. $pagesWithType = $pages->find("content_sections.items.type=image_text"); To get all the texts you need to loop through those pages and get your textfield value foreach($pagesWithType as $p) { $term = $p->get('textfield'); } Or you can get an array of all terms like this $terms = $pagesWithType->explode('textfield'); Seehttps://processwire.com/api/ref/wire-array/explode/ EDIT: removed initial selector added code with loop etc
  23. Time to revive this 8 year old thread 🙂 I'm using vscodium as editor and recently for code formatting I moved from the excellent https://intelephense.com/ extension to an extension that uses https://github.com/PHP-CS-Fixer/PHP-CS-Fixer which is based on https://github.com/squizlabs/PHP_CodeSniffer. This allows custom style definitions (rulesets) https://github.com/squizlabs/PHP_CodeSniffer/wiki/Advanced-Usage#using-a-default-configuration-file PW coding style guide says: Has anybody ever gone through the trouble of creating a custom PW ruleset.xml? Just asking before I start spending my time on that. Other CMSs/Frameworks do have their ruleset files. See https://github.com/WordPress/WordPress-Coding-Standards https://www.drupal.org/docs/contributed-modules/code-review-module/installing-coder-sniffer https://github.com/fossbarrow/laravel-phpcs Would be great if we had one for ProcessWire, too. Maybe @ryan already uses one and can share it? If not, we could start a community effort to produce such ruleset. It would help tremendously for PRs to the PW core or for module development.
×
×
  • Create New...