gebeer

Sorry to say that this error still occurs in my multilang install using PW 3.0.200 on PHP 7.4 both outside and inside repeaters. Required option set either in field or template context yields the same result. Problem seems to be with the isEmpty() method in InputfieldMediaManager.module. Specifcally with get_class($value) == 'MediaManagerArray'. In my install get_class($value) returns 'ProcessWire\MediamanagerArray'. If I replace the check with if(is_object($value) && $value instanceof MediaManagerArray && count($value)) $empty = false; the error is gone.

@kongondo Referring to your post in Media Manager thread, do you think that JqueryFileupload will receive further updates? Just asking so I can decide whether I should fork it and potentially make PRs.

Hi @kongondo and many thanks for this great module. I just installed it on PW 3.0.200 / PHP 7.4 and encountered an issue with uploads of SVG, be it from the MM Upload section or the mm field that I created for type images. FileValidatorSvgSanitizer is also installed. There is a PHP Warning related to JqueryFileuploads module Problem is the getImagesize($imageFile) call which returns false for SVG images. I scanned the JqueryFileuploads thread for posts related to SVG and found none. Wondering if I'm the first one encounterng this. Maybe because it is "just" a Warning and not and Error. I have set Tracy Debugger to strict mode in all of my projects. On https://www.php.net/manual/en/function.getimagesize.php they explicitly say not to use getimagesize for detecting mime size and recommend https://www.php.net/manual/en/function.finfo-file.php instead. Is it possible to make the option allowedImageMimeTypes configurable through module settings or to hardcode image/svg+xml as allowed image mime type into the module? This would make it easier to do mime type validation for svg with finfo_file(). Something like // if (function_exists('exif_imagetype')) { ... } elseif (function_exists('finfo_file')) { $finfo = finfo_open(FILEINFO_MIME_TYPE); // return mime type ala mimetype extension if (in_array(finfo_file($finfo, $imageFile), $allowedImageMimeTypes)) $isValidImage = true; } // ... Or https://www.php.net/manual/en/function.mime-content-type.php is also an option. Feel free to move this to the JqueryFileuploads thread.

You could use it with your RockFrontend UIKit setup because that is based on LESS. But you would have to introduce npm based packages into RockFrontend Unfortunately, they don't provide a pure CSS version of RFS. So I can't integrate it with RockFrontendTailwind since that purposefully uses pure CSS in a PostCSS based build pipeline. Thank you for the links. How would a living Tailwind implementation look like, defining the calculated poly fluid sized font sizes in tailwind.config.js? I like that pure CSS approach. Well thought out. Personally, I also base font sizes, paddings and margins on rem in most cases.

I don't think there is a pure CSS solution for this. You might want to have a look at https://github.com/rikschennink/fitty. Used it in a project and is working great.

Hi there, I am looking for a module that can handle revision scenarios. Usecase: User role foo can edit content. After content changes user role bar needs to approve the edit before it goes live. It is important that changes to already published pages can be handled, too. For new, unpublished pages the PW permission system can do that. But other CMSs like TYPO3 or WordPress can handle multiple content versions and revisions. Hope that something like this exists for PW, too. I found @teppo's https://processwire.com/modules/version-control/ which likely will be needed as prerequisite to handle edits of existing pages that are already published. But couldn't find any revision related modules. EDIT: found a pro module that sounds like it can do what I need: https://processwire.com/talk/store/category/11-prodrafts/

@teppo can this module handle multilang fields? Couln't find anything in the module description or this thread.

Can't confirm that. But one more thing you could try is to extend Page and not RepeaterPage. Just a wild guess but maybe it helps.

The file name and class name are important here. Otherwise PW doesn't know which pages to apply the custom class to. The file name is derived from the template name. See here https://processwire.com/blog/posts/pw-3.0.152/#a-more-practical-example Now you need to find out what the name of the template is, that your repeater pages use behind the scenes. Usually the template name for repeater pages is "repeater_" + fieldname. So if your repeater field is named "my_repeater", the template name would be "repeater_my_repeater". You can look up the template name under Sytem->templates Filters->Show System Templates. Following all that logic in my example, the file name should be Repeater_my_repeaterPage.php and the class name Repeater_my_repeaterPage. I haven't tried this out and I'm not 100% sure about the naming because of the underscores. But in the documentation it isn't mentioned that underscores are converted to CamelCase. So theoretically it should work. Also make sure that custom page classes are enabled in config.php with $config->usePageClasses = true; EDIT: I just saw in https://github.com/processwire/processwire/blob/3acd7709c1cfc1817579db00c2f608235bdfb1e7/wire/core/Templates.php#L853 that underscores are converted to CamelCase, too. So in my example class name would be RepeaterMyRepeaterPage and file name RepeaterMyRepeaterPage.php

Hello all, I have released RockFrontendTailwind, an extension module for RockFrontend. It extends Bernhard's module and adds an installation profile for site development with Tailwind CSS. Obviously RockFrontend is a required dependency for my module to work. This module aims to give you a quick start with a Tailwind based project. What RockFrontendTailwind does: A folder "rockfrontendtailwind" will be installed in site/templates. That folder contains all the configuration files needed to get you started with a webpack-based build pipeline for JS and CSS with webpack tailwindcss postcss with postcss-preset-env (for autoprefixing) babel (for transpiling) So rather than just building the CSS with Tailwind, the build pipeline also takes care of transpiling your Javascript based on configuration in a .browserslist file. Of course, the setup is opinionated. But people who are comfortable working with webpack can easily adjust / extend the configuration to their liking. The default configuration watches your JS and CSS files and compiles them into site/templates/assets main.css and main.js by default. All paths are configurable through a .env file. Live reloading during development is not part of the webpack configuration since this is handled by RockFrontend already in a very efficient way. Also a _main.php file including a very basic boilerplate for a typical setup will be placed insite/templates. It includes examples on how to render your JS and CSS assets. More detailed instructions over at github. Adding new profiles to RockFrontend through your own modules is quite straight forward thanks to the clear structure in @bernhard's module. RockFrontendTailwind can serve as a boilerplate. The only important thing is that the "profiles" folder structure remains the same. The module is currently in beta but runs very stable. It will eventually be released as an official module in the directory soon. If you want to give it a shot, I shall be happy to hear your feedback. If you are looking for a standalone webpack build pipeline with webpack-dev-server, you might want to have a look at https://github.com/gebeer/tailwind-css-webpack-processwire-starter Happy Coding!

In the past I had used the old version of RockMigrations for some simple tasks like adding fields and templates which turned out to be huge time saver. But only just recently I started to use the new version and to discover the possibilities of this tool in more depths. And what should I say, I am really amazed. Once I had grasped the core concepts and, with @bernhard's help, had learned how to use it in a more structured way and in different contexts, it turned out to to be an even bigger time saver. I hate repetitive tasks. Adding fields and templates and fields to templates and configuring labels / access rights etc for fields in the template context in PW is a pleasure when using the GUI. But it is still a repetitive task. With RockMigrations I can have definitions of these fields / templates and fields in template context in a single file and reuse that. In a matter of seconds I have my reusable base structure available to start off a new project. Adding new structure through the GUI in a staging environment and then having to replicate it on the live sytem through the GUI. Repetitive task again. Pushing a migration file to the live system and running the migration. Again in a matter of seconds. Writing migrations wherever I want is also a great feature. Be it inside site/migrate.php or inside a newly developed module, it doesn't matter. RockMigrations will find it and do its job. At the beginning I wasn't sure how to define different field types with all their different properties. RockMigrations comes with VSCode snippets that make things easy. Or you can create a field in the GUI and then just copy/paste the code for the migration from the GUI to your migration logic. So however you prefer to create your fields, RockMigrations has you covered. This post may sound like an advertisement. But I just wanted to express how happy I am after having made the decision to spend some time to learn how to work with this module. That time was definitely well spent. Big thanks to Bernhard for creating this and releasing it as a free module.

Hello, I am reusing a generic image field inside repeaters and need to modify the required minWidth based on the context of the image inputfield. So I have a repeater with fields "images" and "images_layout". Based on the image layout I am modifying image requirements. This is working fine for Inputfield->description or Inputfield->notes. But not for Inputfield->minWidth. The UI does not give warnings if the image size is below the minWidth. Here's my hook code: // add image info to Bilder field inside matrix item depending on layout of images // restrict images with wrong dimensions wire()->addHookBefore('InputfieldImage::render', function (HookEvent $event) { /** @var InputfieldImage $imageInput */ $imageInput = $event->object; // if ($this->user->isSuperuser()) return; $hasPage = $imageInput->hasPage; if (!$hasPage instanceof RepeaterMatrixPage) return; // this example uses repeater matrix but behaviour is same with repeaters if ($hasPage->template->name != 'repeater_content_blocks') return; $ifWrapper = $imageInput->getRootParent(); if($ifWrapper) { $layoutInputfields = $ifWrapper->find('label="Layout Bilder"'); if ($layoutInputfields->count) { $layoutInputfield = $layoutInputfields->eq(0); $layoutField = $layoutInputfield->hasField(); $layout = ($hasPage->get($layoutField->name)->value); switch ($layout) { case 'stacked': case 'stacked169': $dims = array('width' => 2560, 'height' => 1440); break; case 'parallax': $dims = array('width' => 1024, 'height' => 768); break; default: $dims = array('width' => 2560, 'height' => 1440); break; } $imageInput->notes = "Bild-Dimensionen (Breite x Höhe) in px: {$dims['width']} x {$dims['height']}"; $imageInput->minWidth = $dims['width']; // this setting is not respected in GUI $imageInput->maxWidth = $dims['width']; // this setting is not respected in GUI $imageInput->setMaxFilesize('1m'); // 1 MB // this setting is not respected in GUI $imageInput->maxReject = true; $event->object = $imageInput; } } }); When I set the minWidth via images field settings, I get a warning when image is below minWidth But this way I can only set one value for all image input fields in different contexts. When I set the minWidth through my hook to the individual image input fields, I do not get this warning. I would have to use separate image fields for each different context which I want to avoid for maintainability and DB performance reasons. The code in InputfieldImage.module returns $minWidth as empty string when there is no value set by the GUI and this seems to be the culprit. Maybe I need to hook into InputfieldImage::fileAdded to achieve what I want? But in there I also do not have the minWidth available that I set through my hook. So currently I am lost and need some pointers on how to solve this.

Hi, you need to construct the HTML for the link when building the array that you pass to $table->row and set $table->encodeEntities = false; In this example I am building the rows from a pro field table: /** @var TableRows $transactions */ $transactions = $this->wire('pages')->get('template=membership')->membership_transactions; /** @var MarkupAdminDataTable $table */ $table = $this->wire('modules')->get('MarkupAdminDataTable'); $table->addClass('AdminDataList table-striped'); $table->sortable = true; $table->encodeEntities = false; // important $table->headerRow($transactions->getLabels()); /** @var TableRow $t */ foreach ($transactions as $t) { $row = array(); foreach ($t->getArray() as $key => $val) { if ($key == 'id') continue; if ($key == 'member') $val = "<a class='pw-panel' href='{$val->editUrl}'>$val->fullname</a>"; // construct your link here if ($key == 'amount') $val = $val . ' USD'; if ($key == 'date') $val = date('Y-m-d h:i', $val); if ($key == 'status') $val = ($val) ? 'success' : 'failure'; $row[] = $val; } // bd($row); $table->row($row); } return $table->render(); Hope that helps.

Thank you for all your valued feedback so far. This is an opinionated setup, like almost all of webpack setups are in a way. I'm using this as a working starter and therefore tried to keep it as lean as possible, only concentrating on tailwind, postcss, babel. If I needed to add other libs like Alpine etc. it can be easily extended.

That sounds intriguing. I'm happy with my setup and the build time is pretty fast already. Seems like every couple of years a new tool is being hyped as faster, easier, better etc. I'll definitely have a look at vite but for the moment I'm going with webpack. A repo where we can look at some vite setup code with PW would be welcome. Don't think it is necessary to have a tutorial, though. I am sure there are tons out there already. But thank you.

Oh, I see. The feature request is about improving documentation and giving developers a way to disable stripping of comments.

Thanks again for the suggestion. I really don't want to spend more time for finding a workaround. I'll be waiting until we get some feedback in the feature request and a clean way to avoid stripping comments. In the meantime, I fell back to good old if statements for including the necessary HTML blocks.

I have setup a starter kit for developing PW sites with Tailwind CSS. You can find it at https://github.com/gebeer/tailwind-css-webpack-processwire-starter I know, I'm a bit late to the party with Tailwind. In fact I only discovered it a couple of months ago and found it to be a very interesting concept. It took quite some time to get a pure webpack/postcss/tailwind setup that features live reloading dev server, cache busting, supports babel as well as autoprefixing and works well with PW. For the cache busting part I developed a small helper module that utilizes webpack.manifest.json to always load the assets with the correct file hashes for cache busting. No more timestamps, version numbers or the like required. The little helper can be found at https://github.com/gebeer/WebpackAssets Having used it for the first time in production on a client project I have to say that I really enjoy working with Tailwind. The concept of using utility classes only really convinced me after having put it to practice. During the work on the client project, some quirks with webpack-dev-server came to surface. I was able to solve them with the help of a colleague and now it is running quite stable in both Linux and Mac environments. I am fascinated by the fast build times compared to using webpack/gulp or gulp/sass. Also the small file size of the compiled CSS is remarkable compared to other frameworks. So this will be my goto setup whenever I am free to choose the frontend framework for a project. If anyone feels like they want to give it a try, I shall be happy to get your feedback

Unfortunately this is not working. And it looks ugly and feels so wrong ;-) But thank you for the suggestion.

This only helps in some cases. In my case I need the comment to read <!-- ko if: properties.ms == "pro" --> for knockout.js to recognise it. So the other syntax would break my JS. But thanks for pointing that out.

I made a feature request for documentation improvement: https://github.com/processwire/processwire-requests/issues/454

Hello, MarkupRegions is stripping out HTML comments by default. I just discovered that while converting a rather old project to use MarkupRegions. In that project HTML comments are required for some knockout.js code to work. And I was scratching my head for quite a while until I recognized that those comments got removed. This behaviour is nowhere being mentioned in the documentation, other than in the code itself at https://github.com/processwire/processwire/blob/3acd7709c1cfc1817579db00c2f608235bdfb1e7/wire/core/WireMarkupRegions.php#L89. And an old forum post mentions it. How can I tell MarkupRegions that my markup is required to stay exactly the same or in other words, where can I pass options ("exact" =>true) to MarkupRegions find() to change the default behaviour?

You might want to have a look at https://processwire.com/modules/less/ and https://processwire.com/modules/sassify/ for example implementations of parsers. I don't quite see an advantage on compiling frontend assets on the server. Except for themes that want to provide customisations without the need for coding. One module for each frontend package seems like a reasonable way to go but keeping those up to date will also be quite time consuming for the maintainer. This is where package managers come in handy. So, if you can find composer packages like BS and UIkit that you can utilize for the PW modules than that would be a big time saver.

Unfortunately we where not on InnoDB. But the problem was not so much memory consumption but rather long execution time for saving pages. Total mem consumption after saving values to 2500 pages was around 45MB only.

Yes, it would for sure. I recall that Ryan was talking about making the PW API available through JS some years back. That would be exactly what we need. A RESTful API like the WP REST API in ProcessWire. This should ideally be available as an optional core module and support all Pro fields.