Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 08/26/2024 in all areas

  1. Process Render File A Process module that renders markup from files in /site/templates/ProcessRenderFile/. This provides an easy way to create simple admin screens where it might be overkill to create a dedicated Process module for the purpose. Process page When you install the module a page with the name "render-file" and the title "Render File" is created under Setup. To change the page name or title, expand Page List to Admin > Setup > Render File and open the page for editing. Tip: if you create a new text field with the name "page_icon" and add it to the core "admin" template you can set a custom menu icon for the page by entering the icon name into the field. E.g. enter "smile-o" to use a smiley icon for the page. If you want to use ProcessRenderFile for more than one Process page you can create a new page under Setup. Select "admin" for the template, enter a title for the page, and in the next step choose ProcessRenderFile in the Process dropdown. Render files for URL segments On install the module will create a "ProcessRenderFile" folder in /site/templates/. Any .php files you save to this folder will be rendered as the output of a matching URL segment for Process pages using ProcessRenderFile. For example, if you create a file foo.php containing code... echo "This is the output of foo.php"; ...then you'll see this output when you visit /processwire/setup/render-file/foo/ (assuming the default ProcessWire admin page name and the default ProcessRenderFile page name). In the render file you can use all the ProcessWire API variables like $pages, $input, etc, as you would in a template file. If you create foo.js and foo.css (or foo.scss if you have ProCache installed) then those assets will be automatically loaded when you visit /processwire/setup/render-file/foo/. When a file is rendered the filename will be converted into a capitalised format that's used as a browser title and a headline. If you want to set a custom browser title and/or headline you can do this in your render file: $this->wire('processBrowserTitle', 'Custom browser title'); $this->wire('processHeadline', 'Custom headline'); Render file for the Process page If you create a render file that has the same name as the ProcessRenderFile Process page then this file will be rendered when the Process page is viewed without any URL segment. So for the default ProcessRenderFile page name you would create render-file.php. Note that this will override the default list output described below. Configuration The module configuration screen lets you select URL segment render files to appear as menu items. The selected render files will appear in the flyout menu for the Process page, and also as a list when the Process page is viewed without any URL segment. The list is only shown if you haven't created a render file for the Process page as described above. If you've created more than one ProcessRenderFile Process page then you'll see menu options for each page in the module configuration. https://github.com/Toutouwai/ProcessRenderFile https://processwire.com/modules/process-render-file/
    11 points
  2. This week the most useful core update is likely the refactored column width slider in the template editor, located Setup > Templates > [your template] > Basics > Fields. You may or may not already know that clicking, holding and dragging the percent indicator on the right side of each field adjusts the column width. With the term “column width”, I mean the width of the field in the page editor, for when you want to have multiple fields in different columns on the same row. It’s a convenient and time saving shortcut. But it was also a little tricky to use, as it allowed anything between 10% and 100% in 1% increments, and it was a little finicky trying to get the percentages just right sometimes. It’s something that’s been bugging me for awhile, and @Pete messaged me on Slack this week and mentioned it. He suggested making it operate in 5% increments rather than 1% increments. He also suggested making a double click of the percent indicator open up the dedicated column width range slider that allows for more precise adjustments. I thought those were good suggestions, so I went ahead and implemented them this week. In addition to now using 5% increments, it also supports the commonly used 33%, 34% and 66% width values as well. But if you happen to already have some field that is using a less common width, like 27% or 72%, etc., then it reverts back to 1% increments for the same behavior as before. Of course, you can also use the 1% increments by double clicking the percent indicator to open the dedicated column width range slider. Thanks Pete for the suggestions, I think it all works better now. I’ll be applying the same changes to FormBuilder’s equivalent of this feature as well. This week I’ve also been working on the new CustomFields modules (FieldtypeCustom and InputfieldCustom). Most recently I’ve been working on adding support for multi-language fields, as well as adding more examples and tools to make it really easy to use and configure. I may have it ready as soon as next week or the following week. The PageAutosave module is also getting a new version soon. I’ve been focused on the LivePreview feature of it and making a version of it that doesn’t depend on auto-save. The alternative LivePreview option (which we’ll just call “Preview”) will work anywhere because it has no field limitations. It simply updates the preview window whenever you save the page. While that’s not as fancy as live preview as-you-type, it’s still very helpful, while being reliable in any situation. It’s reliable and portable enough that I may end up putting the feature in the core, but will be testing it out in the next version of the PageAutosave module first. Have a great weekend!
    3 points
  3. I only build websites in black and white. Color is a paid extra.
    3 points
  4. Nicely said @Pete. I have struggled with mental health in the last 10 years and I actually find the ProcessWire forums with its community to be a relaxation tool for me. I love seeing people help each other every day and that makes me feel positive about the world. Sounds corny I know.
    3 points
  5. Ah man I know what you mean - a long time ago (2012-14 maybe) I was here daily and I probably need to hang around here using the time I normally waste reading the news which is way less healthy for my brain. Or tapping away on other nonsense on my phone for hours.
    2 points
  6. Great! This has been annoying me over the last few days as well (and on any previous project), but it was not annoying enough to have the idea of supporting custom stubs per project so your input was highly appreciated ? If any of you guys have any other suggestions how to further improve the day to day development experience when using RockPageBuilder please let me know!
    2 points
  7. Here you go: This version will be merged next week. I'll send you a copy to test!
    2 points
  8. @Stefanowitsch many thanks for sharing your solution, really helped me out. I modified it a little when implementing. Does the same job but may be a little more optimized. <?php $wire->addHookBefore('Pages::saveReady', function($event) { // ...rest of code here $page->block_search_cache = $index; // By hooking before the saveReady event it's possible to set the search cache field value without calling an extra page save // $page->save(['noHooks' => true]); }); Worked for me and just thought to share. Thanks again!
    2 points
  9. @virtualgadjo I was able to find a similar conversation on a RPB module support thread and put something together. I did take an idea from you using the Pages::saveReady event rather than the Pages::saved event in that example which I like better. Same setup with the extra field as you have done. In case this helps anyone else, here's what I came up with. It may be useful outside of the context of RockPageBuilder where field types matter. /** * Adds any content in RockPageBuilder field blocks to the dedicated indexable search_engine_block * field that it then added to the search index */ $wire->addHookBefore('Pages::saveReady', function($event) { $page = $event->arguments(0); // Get only RPB fields if they exist $rpbFields = array_filter($page->fields->getArray(), function(Field $field) { return $field->type instanceof FieldTypeRockPageBuilder; }); if (!$rpbFields) { return; } // Map RPB fields with values from getSearchIndexValues method if it exists on the child block $indexableContent = array_map(function(Field $rpbField) use ($page) { $blocks = $page->getFormatted($rpbField->name)->getArray(); // Merge content for each block within a field into a single array return array_reduce($blocks, function($values, $block) { if (!method_exists($block, 'getSearchIndexValues')) { return $values; } return $values = [...$values, ...$block->getSearchIndexValues()]; }, []); }, $rpbFields); // Flatten array of arrays containing index-prepared content $indexableContent = array_merge(...$indexableContent); if ($indexableContent) { // This is where it may be improved to make use of a SearchEngine method $page->search_index_blocks = implode(' ... ', $indexableContent); } }); The last comment is right above where I think it would be useful to see if there's a way to make use of the SearchEngine object to index content. My implode() method is mimicking the format of the search_index field with ' ... ' but deferring that rather than mimicking it would be great. It's not a dealbreaker but it would help keep my code from knowing too much about how SearchEngine works internally. Thanks @virtualgadjo for sharing!
    2 points
  10. While working with RPB I have started to modify the stubs in the /modules/RockPageBuilder/stubs directory because, while the advanced block stub has been great, I realized that there is a lot of boilerplate that evolves into projects and I found myself consistently having to copy/paste contents from existing blocks to new blocks when created. I've been editing the stubs in the RPB module directory but have to be sure that I re-copy my custom stubs after upgrading the module. Perhaps there could be an option to "Publish Block Stubs" on the module configuration page. It could create a /templates/RockPageBuilder/stubs directory where the default stub files could be copied to and would be used for creating new blocks when they exist. I've created several support classes/objects that help with speed and consistency when working with blocks and having have new blocks created from customized files would be super awesome. Inspired by Laravel's publish stubs feature ?
    1 point
  11. @bernhard Oh heck yeah!!! That's going to be a gamechanger for me and really appreciate it!
    1 point
  12. https://github.com/dtjngl/DiagnosticLogger # DiagnosticLogger Do you struggle like me with keeping track of updates across multiple website projects? Do you also feel like your clients are unaware of what web development maintenance involves? Do you sometimes feel unappreciated for your hard work? If so, here's a solution for you. It's not perfect, but it's a start. **DiagnosticLogger** is a ProcessWire module designed to handle diagnostic logs and create notifications in the admin GUI. It can also send automated email summaries for warnings and errors found in these logs. ## Features - **Log Handling**: Captures and processes diagnostic logs. - **Admin Notifications**: Displays notifications within the admin GUI for detected issues. - **Email Summaries**: Sends automated emails summarizing warnings and errors. ## Integration The module integrates with **ProcessDiagnostics**, which is required for its functionality. It is designed to work seamlessly with ProcessDiagnostics but is not highly configurable. ## Important!! I wasn't able to accomplish this in the hook from inside the DiagnosticLogger class so you need to add these lines in the ProcessDiagnostics.module file to make this work. public function ___execute() { wire('log')->delete('diagnostics'); // to not be redundant // … foreach ($results as $caption => $section_results) { // … foreach ($section_results as $k => $row) { // … wire('log')->save('diagnostics', '|' . $row['title'] . '|' . $row['value'] . '|' . $row['status'] . '|' . $row['action']); } } } This will log the diagnostics everytime the ProcessDiagnostics runs. I still haven't figured out how to run diagnostics automatically or schedule them. ## Workaround for Background Diagnostics The logging feature acts as a workaround due to difficulties with running diagnostics in the background. The hooked method from ProcessDiagnostics will need to be made hookable for better integration. ## Configuration 1. Access the configuration settings in the ProcessWire admin interface. 2. Adjust the settings according to your needs. ## email LazyCron Scheduling For scheduling tasks using LazyCron, for example: - every2Weeks: Runs tasks every two weeks. - everyDay: Runs tasks every day. - everyWeek: Runs tasks every week. ## Installation 1. Download the module and place it in the `site/modules` directory. 2. Log in to the ProcessWire admin interface. 3. Go to Modules > Refresh. 4. Locate **DiagnosticLogger** and click **Install**. ## Usage Once installed, **DiagnosticLogger** will automatically start processing diagnostic logs. You can view notifications in the admin GUI and receive email summaries based on your configuration. ## Requirements - ProcessWire 3.x or later - ProcessDiagnostics module
    1 point
  13. I think you're right, and some things like Robin's module there are definitely things that could benefit from being in the core as it just makes sense - @ryan please do take a look at this one as it's incredibly useful to visually see how the fields will flow as well as in tabs etc and would be nice if it was in the core too as I don't think it would add much to it but add a lot of benefit to folks who launch sites regularly. This is a bit of a tangent but talking about mental health is less taboo nowadays and I'm sure someone else here will relate - having recently been diagnosed with ADHD I tend to let myself off the hook a bit more now with my forgetfulness. I used to beat myself up about it but the fact is that something needs to be deeply engrained into my day-to-day work to remember it so modules that might help me with setup at the start of a project like TemplateFieldWidths are long forgotten by the end of it ? It's also why I can write PHP and build big projects but cannot hang onto the terminology at all. Like people talk about closures and my brain can rarely remember what "operand" means some days but I can write it all... just the labels on my internal glossary/filing system aren't stuck on very well and keep falling off it feels like. I spent until I was 43 amazed at how people can learn stuff and retain the knowledge so well. I'm very thankful to be pretty good with computers and good enough as a developer that I can do this for a living and live pretty well.
    1 point
  14. I became so used to use Template Field Widths that I almost always install it on larger projects. Super fast editing of values, tabbing around and done.
    1 point
  15. Here's my solution to this. For anybody who might integrate it in a similar way: 1. Create a custom search index field and add it to the page templates that should be included in the search. The idea is that all RockPageBuilder blocks on a page will write "their content" into this field so that when searching for keywords the corresponding page (that includes a block) will be listed 2. Create a method called "createIndex" in each RockPageBuilder block class that you want to include in the search results. For example a simple Textblock would only return its body field: public function createIndex() { return "{$this->body}\n"; } 3 Make use of the Pages::saved Hook in ready.php to save the content of all RockPageBuilder bocks into the search index field: $wire->addHookAfter('Pages::saved', function($event) { $page = $event->arguments(0); $index = ''; // Iterate over all fields on the page foreach($page->fields as $field) { // Check if the field is of the type used by RockPageBuilder if ($field->type instanceof FieldTypeRockPageBuilder) { // Get the formatted content of the field $blocks = $page->getFormatted($field->name); // Further processing of the blocks if needed foreach($blocks as $block) { if (method_exists($block, 'createIndex')) { $index .= $block->createIndex(); } } } } //bd($index); // Save index to custom search index field $page->block_search_cache = $index; $page->save(['noHooks' => true]); }); 4. Inside your search template you can search for pages that contain blocks like this: $matches = $pages->find('block_search_cache%=' . $q);
    1 point
  16. @Spinbox, @alexm, Padloper 010 was released this week, in case you missed it ?.
    1 point
  17. Hey @alexm, Done! In upcoming version 010. Thanks.
    1 point
  18. I can tell you how to transfer me the $9995 you could not get rid of, just PM me ?
    1 point
  19. Good day everybody! When I think about TracyDebugger, I always think about the invaluable functionality of this must-have module. But yesterday I had a new impression about TracyDebugger - its super appealing design (in places). I was installing Tracy on a new site and was astonished by the new look of a "Donate" button in the module config. It is super simple and probably even a standard PayPal button, but it's placement and a color contrast just struck me. I could not resist, clicked the button and made a $10000 donation. This is by far less than the value this module gives me, so wanted to give something back (and the magic button did its job, of course). But must be something with PayPal in Russia that it only let $5 of my donation pass though ?. So I suggest everybody go look at this button in the TracyConfig to learn some useful marketing tricks. And if you happen to be somewhere outside Russia please click on it and try to make a more than $5 donation to check, if the same limits apply in your country. So we can report to PayPal or something)))
    1 point
×
×
  • Create New...