Jump to content

gebeer

Members
  • Posts

    1,386
  • Joined

  • Last visited

  • Days Won

    39

Posts posted by gebeer

  1. On 2/7/2023 at 1:42 AM, patman said:

    I fixed the PHP 8 issues and also the problem mentioned in my previous post. See my pull request https://github.com/BlowbackDesign/EmailObfuscation/pull/15 for a solution.
    If someone has the opportunity please test and report back if there are issues. Actually, it should be a drop-in replacement. @Roope please consider my PR after testing.

     

    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. 13 hours ago, bedak said:

    After upgrading from 3.0.213 to 3.0.214 (using PHP 8.0.28) I get the error message "ProcessLogger: Unknown log: <protocol-name>" when clicking on a protocol-name. And the size-column and the changed-column showing the same values for all listed protocols.

    If I replace the method `getLogs()`  in /wire/core/WireLog.php by `getLogs()`  of the version of 3.0.213 everything is ok again...
    Can anyone confirm this errpneous behavior. Thanx! 

    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.

    • Like 2
  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. 3 hours ago, dotnetic said:

    It would be nice, if you can quickly navigate from one recipe to others. There are several ways this could be done. A search function would be one option, or an iframe as a sidebar with all recipes.

    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.

     

    3 hours ago, dotnetic said:

    How can I improve a recipe because there are better (newer) methods to accomplish the same? Create a PR for that recipe? Or create a new recipe with the same title with the improved method?

    I'd opt for PR to that same recipe. There's no need to keep around old outdated versions if improved ones exist.

     

    3 hours ago, dotnetic said:

    There should be a ProcessWire version field, so someone knows that one method only works with a specific version of PW.

    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

    • Like 3
  6. 15 hours ago, kongondo said:

    I thought a bit about using the inbuilt image tags but now I am leaning toward saving these separately as 'categories', one per page.

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

    • Like 1
  7. On 3/11/2023 at 10:58 AM, wbmnfktr said:

    I wish we could create some sort of snippet collection (right now) from all of these recipes in some kind or another.

    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.

    On 3/11/2023 at 10:58 AM, wbmnfktr said:

    But first we should define a default/standard format for recipes and go from there.

    I wish we could go through all of the recipes to make them some kind of uniform, working with ProcessWire 2+, and mark those which only work with ProcessWire 3, or whatever version of ProcessWire, just to find a solid foundation.

    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.

    On 3/11/2023 at 10:58 AM, wbmnfktr said:

    Something I forgot... there are snippets, ready.php snippets, common hook snippets... and probably more... so we have to classify snippets and recipes right from the start in some kind.

    Couldn't we also use tags for that, like "init", "ready", "hook"? EDIT: I just did that and made a PR.

    • Like 1
    • Thanks 1
  8. 3 hours ago, gebeer said:

    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.

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

    • Like 2
  9. 40 minutes ago, BrendonKoz said:

    Hi @gebeer! I'm currently using RepeaterMatrix with SearchEngine successfully, though I'm not using any non-native PW FieldTypes. I did run into an issue where RepeaterMatrix-based fields, if customized by a template to not include one of it's available fields would cause an error and not complete the index. I have a pull request pending for the repository which, in my testing, seems to have fixed the problem.

    Although I suspect this might not be your issue, I wanted to share on the small chance that it does help.

    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.

    • Like 1
  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?

    • Like 5
    • Thanks 1
  12. 13 hours ago, kongondo said:

    Otherwise, if one drag and drops whilst viewing a certain category, that media will be assigned to that category.

    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.

     

    13 hours ago, kongondo said:

    Yes, we can have a setting for 'default' category, maybe even separate for the 4 media types (just brainstorming here!).

    I agree this should be separate from the media types. Maybe something like "uncategorized"

    13 hours ago, kongondo said:

    Can a media belong to more than one category? Either way is doable;

    This should definitely be possible. So media that has multiple categories would appear in multiple virtual folders.

     

    13 hours ago, kongondo said:

    By tags, do you mean the inbuilt ProcessWire image/file fields tags?

    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.

    13 hours ago, kongondo said:

    A question to you all, how does the powerful but potentially confusing inputfield selector work for your clients? Do they use it or would you prefer a simpler interface

    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? 

    7 hours ago, David Karich said:

    When you click on "People", only two folders are displayed, but no pictures from both subfolders. I would also prefer this. Inheriting subitems in the view works well for a few folders, but not for 20, 50, 100 and then recursively over several levels lower.

    Totally agree. It could be a configurable option whether to include files from subfolders in the view or not.

    5 hours ago, nurkka said:

    Also a more compact view for pdf documents would be great, because the current grid and list view both require a lot of space if one has some hundred pdfs in the library. In a past project I added the pdf filenames to the grid view by modifiying some javascript files, to have a more compact view with the filenames visible. Perhaps, pdf icons could be a lot smaller or omitted at all in the document view.

    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?    

    • Like 1
  13. 9 hours ago, David Karich said:

    And the biggest wish I have to pass on: Folder, folder, folder. My clients love thinking in folders.

    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.

    • Like 1
  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. On 9/19/2022 at 10:09 PM, artfulrobot said:

    (I'm specifically looking for how to create a page with several pagetable field values programmatically).

    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.

    • Like 3
  16. 5 hours ago, gornycreative said:

    Perhaps referring to an undeclared index?

    Unfortunately not anymore since 8.0. The docs say

    Quote
    • A number of notices have been converted into warnings:

       

      • Attempting to read an undefined variable.
      • Attempting to read an undefined property.
      • Attempting to read an undefined array key.
      • Attempting to read a property of a non-object.
      • Attempting to access an array index of a non-array.
      • Attempting to convert an array to string.
      • Attempting to use a resource as an array key.
      • Attempting to use null, a boolean, or a float as a string offset.
      • Attempting to read an out-of-bounds string offset.
      • Attempting to assign an empty string to a string offset.

    But thanks for looking into it 🙂

     

  17. 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

    438871294_2023-02-28-095512.png.f74889dc3f5e148617d182ccb6394db9.png

      

    • Like 2
  18. 3 minutes ago, alexm said:

    Sorry @gebeer I should have added, that yes when I add the addition of include=all it works just fine, but I don't understand why I would need to for this use case? Is it something to do with the fact that "hero_image_section" is a FieldsetPage and therefore it's another page it's getting the image from?

    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.

  19. 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

    • Like 1
  20. 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:

    Quote

    The ProcessWire coding style guide is based on PSR-1 and PSR-2 (with many sections copied directly from them), but with several important differences and additions.

    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.

    • Like 3
×
×
  • Create New...