Leaderboard

Just released Wireframe 0.7.0. This version is all about caching: when requesting Controller methods from view (<?= $this->some_controller_method ?> etc.) the return value is now cached (runtime cache). Additionally if method names are added to protected $cacheable_methods property of the controller class, along with an applicable expire time (i.e. "protected $cacheable_methods = [ 'method_name' => 3600 ]"), Wireframe automatically caches the value using WireCache (persistent cache). Caching is usually a good thing, but not always preferred, which is why runtime caching can be prevented by adding the method name to (protected) Controller property $uncacheable_methods (protected $uncacheable_methods = [ 'method_name' ]). Persistent caching is always opt-in. Changelog: ### Added - Runtime caching support for Controller method return values. Values are cached *unless* the name of the method is found from Controller::$uncacheable_methods. - Persistent caching support for Controller method return values. Values are cached only when found from the Controller::$cacheable_methods array. ### Changed - In the View class all internal requests for Controller properties are routed through View::getFromController().

Ciao Franciccio, where this class lives into your template file? On the body tag? Are you using it to style the whole page differently according to its content? In this case you could add those classes programmatically according to the page you're serving, using just one template file. (btw I'm italian too, write me a pm if you're in trouble and I will send you my skype username there, but first let's try to solve this inside the forum).

Keep an eye on the Changelog page too. I find they regularly introduce nice additions to the framework.

FIXED!!! I was not using the current version, which is 3.2.2. feel like such a dummy LOL

A couple of hooks that I have found useful in some situations... In the admin menus the icon associated with each page is normally determined by the "icon" item in the Process module config (e.g. as set in the getModuleInfo() method). But sometimes you might want to change that icon. For example, the Lister Pro module uses the "search-plus" icon, but this is not so good when you have multiple Lister Pro instances because it makes each instance less distinct. With the hook below I can use a custom icon for the extra Lister Pro instances I have added: // Add custom icons to Lister Pro menu items $wire->addHookAfter('Page::getUnknown(page_icon)', function(HookEvent $event) { $page = $event->object; if($page->process == 'ProcessPageListerPro') { if($page->title === 'Flora species') { $event->return = 'leaf'; } elseif($page->title === 'Flora images') { $event->return = 'picture-o'; } } }); If you change an icon in the admin menus like this you can do a Modules > Refresh to clear the menu cache and see the updated icon. And for Page List you probably know that you can assign an icon to all pages that use a template in the template's "Advanced" tab. But with the hook below you can assign icons to pages more dynamically based on any properties of the page. So, for example, you could assign a warning icon to a page to alert site editors if some important field was left empty. // Add warning icon to news items without a date $wire->addHookAfter('Page::getIcon', function(HookEvent $event) { $page = $event->object; if($page->template == 'news_item' && !$page->date_1) { $event->return = 'exclamation-triangle'; } });

Yep, because of the way this module works, it can only limit to one branch of the tree. This limit affects all places where the user could view and/or edit pages outside that branch. If you want to give access to multiple branches you'll need a different approach - this thread might be helpful:

use a hook? https://processwire.com/api/ref/fieldtype/create-field/ or wait for impeachment? ?

Why do you need to test them so often? The obvious advice would be: Test them on the development instance of the site. Depending on embed method (A-D), a query string may or may not work. Perhaps with a hook that checks for user-role? $this->addHookBefore('FormBuilderProcessor::emailForm', $this, 'testEmails'); protected function testEmails(HookEvent $event) { /* @var InputfieldForm $form */ $form = $event->arguments(0); if ($user->hasRole("email-tester") && $config->emailTesting === true) { $recipient = $form->getChildByName('recipient'); $recipient = 'foo@admin.com'; // or put inside $config too // some re-definition of the landing page, e.g. add query string or pseudo-landing page, or real-landing-page-url + url-segments /test-only/ } }

Normally you can use Processwire, however I would imagine you would have to build a lot of things around Processwire's API personally I would find it easier to go with an application framework, as that would give me more freedom around the architecture. You would need to know alot about Processwire API to pull that off, but it is possible, in one of my threads, I played with the concept of having a MVC like structure. So the choice is up to you. But personally for that type of application I would go towards an application framework, as I would imagine you would need much more frameworks around caching, DB ORM.

Google 'professor messer' and check out a course on Udemy, a course by Chris Bryant for CCNA video bootcamp.

The answer was $page->tablefield->removeAll(); got there in the end ?

Snippet for adding a module config class: "Module Config Class": { "prefix": "moduleConfig", "body": [ "class ${YourModule}Config extends ModuleConfig {", " public function getDefaults() {", " return [", " 'fullname' => '',", " ];", " }", " public function getInputfields() {", " \\$inputfields = parent::getInputfields();", " ", " \\$f = \\$this->modules->get('InputfieldText');", " \\$f->attr('name', 'fullname');", " \\$f->label = 'Full Name';", " \\$f->required = true;", " \\$inputfields->add(\\$f);", " ", " return \\$inputfields;", " }", "}", "", ], "description": "Module Config Class" },

@bernhard many thanks for your PM help. For everyone else who might have the same problem as me, here are my implementation steps (no guarantee - I'm not a programmer) 1. activate URL segments (a good introduction can be found here: https://processwire.com/docs/front-end/how-to-use-url-segments/) 2. create my page WITHOUT URL segment (this shows the content + a button) 3. create a new page for the URL segment (e.g. /pdf) - this creates the PDF and displays it e.g. with show(). 4. it works ? My Code from No 2 (content + button) - mytemplate.php <?php if(strlen($input->urlSegment2)) throw new Wire404Exception(); switch($input->urlSegment1) { case '': // Segment 1 is empty so display main content <!-- my main content --> // My button to the PDF-creation-code echo "<a href='". $page->url ."pdf/' target='_new'>generate PDF</a>"; break; case 'pdf': // Display the PDF include 'mytemplate-pdf.php'; break; default: // Anything else? Throw a 404 throw new Wire404Exception(); } ?> My code for example from No 3 (PDF creation) - mytemplate-pdf.php <?php $pdf = $modules->get('RockPdf'); $mpdf = $pdf->mpdf; $pdf->set('SetHeader', 'This is my header text'); // Two different ways to generate an output $mpdf->WriteHTML('Hello World ' . date('H:i:s')); $pdf->write('<!-- my custom comment --> Foo Bar Foo Bar ...'); // Output $pdf->show(); // to directly show your file in the browser ?>

This latest version on the dev branch includes a few additions, optimizations and fixes. I'm only in the office for a brief time today, so I'll plan to cover these in more detail hopefully in next week's blog post (along with next week's updates), but here's a preview. There's a lot of improvements to the "Overrides" tab that you see when editing a field (Setup > Fields > Edit). These are the field settings in the contexts of different templates. In 3.0.144, you now get a list of all field settings that you want to allow to be customized per-template. In previous versions, you only saw this option if you were in $config->advanced mode. It's still a YMMV setting, so appropriate disclaimers have been added to the field. But since it's been there for more than a year and there have not been any reports of issues (that I'm aware of yet), I thought it didn't need to be limited to advanced mode anymore. The table that shows you what overrides are in place is now improved as well. You can now click any override setting to open a modal window to see/edit them as needed (previously they were just non-clickable text labels). This is the same window that you get when clicking a field in the Template editor. Though unlike the Template editor, it takes you directly to the setting you clicked on and highlights it. After saving or closing the window, it updates the table for any changes you made. In addition to this, the overrides table now shows a Diff rather than separate Old and New values for modified settings, which better clarifies what was changed. (That Diff comes by way of a new method added in the WireTextTools class). Version 3.0.144 also adds a new Inputfields Javascript API. More methods are likely to be added to it, but you can see what's available in this first version in the comments for this file (inputfields.js). The purpose of this Inputfields JS API is to make it simpler to manipulate Inputfields from the JS side, as well as solve some needs that I've had in the core and modules; which presumably some other developers may have had as well. It takes a lot of stuff that previously required knowing which classes and attributes to manipulate and simplifies them to simpler methods calls from the new Inputfields JS API variable. It also abstracts away some admin-theme specific stuff so that you can use the same API to perform certain manipulations regardless of admin theme. I'm still working out some details and likely have some issues to fix and additional functions to add, so I'll save examples and more description for next week. Though the updates mentioned for the "Overrides" tab do use a little bit from this API. This version also contains a couple of fixes per GitHub issue reports, and that'll continue into next week's version as well. More updates next week. Until then, thanks for reading and have a great weekend!

There is kind of built in support for this; - Edit the admin template and add a text field with the name "page_icon" - Go to the admin page tree, search for your lister pages to edit: – Add the fontawesome icon name without the fa- part… Voila: Thanks to @ryan for pointing me to this solution in a support request… ?

On a loosely related note: in case you already serve your content via HTTP/2, combining files is often less important. In some cases it may even be the opposite: technically the optimal use case would involve combining JS files into separate, smaller bundles that contain related features. "One big blob of JS" is very close to an antipattern these days. Just my five cents. Overall what I'm trying to say here is that if you're using HTTP/2 (which you should – and if not, that's something to focus first anyway) I wouldn't worry too much about bundling files, unless you've got loads of them ?

Seems like procache minify removes a trailing slash within embedded svg files tags ( path, polygon, rect etc ) It causes the svg not display correctly in Safari and Chrome. How do I force it to keep that slash? Thanks