Leaderboard

Thank you very much @Robin S I modified the code a little bit to fit my needs and now it is a rally simple but very effective solution for handling global media / file management in ProcessWire.

@ryan still none of my paid modules show up in the modules directory. Also do you have some feedback on my questions/suggestions from 4 weeks ago here and here? I'd like to know if you plan to add the suggested improvements or if I have to update all my modules manually. When I look at the RockPageBuilder module it (still) looks like this: Is that warning really necessary? Why is that warning shown to regular (non-logged-in) users? IMHO it doesn't add any helpful information for them. How would a guest user add or update the readme of my module? I understand that my module does not have a readme, but it has extensive docs here: https://www.baumrock.com/en/processwire/modules/rockpagebuilder/docs/ I put a lot of effort into these docs so it is frustrating that all that is visible in the modules directory is an ugly red warning. Even worse I think this warning can make the impression that the module is dead or not actively maintained, which is not the case and which would be harmful to my business. The "Project" button does nothing when I click on it. What is it intended to do? And why does it appear on my modules page? And all that said, why does that lead to my modules not being shown in the list of paid modules? Or is there another reason for that? Next, a minor thing: Why does it show "Since 2025/01/10" and does it have to be like this? On my releases page the oldest release is v3.6.0 from January 2023 and it would be nice to make it obvious that this module has a long history and has always been actively maintained, updated and improved. I understand that this is likely the date when I added the module to the directory, but it's imho nothing that adds value to my module's entry. Could that be made configurable so that I can show the real release date or instead only (not additionally) show the last updated date there, which would be more helpful information for anybody I guess? Thx

Of course RockMigrations can do that. Example migrate.php: <?php namespace ProcessWire; $rm = rockmigrations(); // install modules $rm->installModule('TracyDebugger'); $rm->installModule('RockDevTools'); $rm->installModule('RockFrontend'); $rm->installModule('AdminThemeUikit', [ 'toggleBehavior' => 1, // consistent 'themeName' => '', // original theme ]); $rm->installModule('RockAdminTweaks', [ 'enabledTweaks' => [ 'General:QuickAdd', 'Inputfields:CopyFieldNames', 'Inputfields:ImageDownload', 'PageList:TemplateLink', 'PageEdit:PrevNextPage', ], ]); $rm->installModule('Less', [ 'useCache' => 1, ]);

@Stefanowitsch asked about using the File Mover module with a "media library" page that is accessed via a modal. I thought I would share some hook code publicly in case it's useful for others too. // Add a button to file and image fields to open a media library page in a modal // Hook InputfieldFile::render to affect file and image fields, // or InputfieldImage::render to affect only image fields $wire->addHookAfter('InputfieldFile::render', function(HookEvent $event) { $inputfield = $event->object; // The field associated with the inputfield (if any) $field = $inputfield->hasField; // The page containing the inputfield (if any) $page = $inputfield->hasPage; // Don't add the button to fields on the media library page // as we don't want the possibility of nested modals if($page && $page->template == 'media_library') return; // You can also check the field name if the button should only be added to a specific field, e.g. // if($field && $field->name !== 'article_images') return; // Get the media library page $media_library = $event->wire()->pages->get("template=media_library"); // Construct the URL to edit the media library page $url = $media_library->editUrl; // Add &modal=1 so the admin header isn't shown $url .= '&modal=1'; // We don't need other tabs or fields besides the image/file field(s), // so specify the field name(s) in the URL // Unfortunately there is this layout bug: https://github.com/processwire/processwire-issues/issues/1972 $url .= '&field=images,files'; /** @var InputfieldButton $f */ $f = $event->wire()->modules->get('InputfieldButton'); $f->href = $url; $f->value = 'Open media library'; $f->icon = 'picture-o'; // Add pw-modal class so the button link opens in a modal $f->addClass('pw-modal'); // Make it a large modal $f->addClass('pw-modal-large'); // Add a bit of space above the button $f->attr('style', 'margin-top: 10px;'); // Append the rendered button to the inputfield $event->return .= $f->render(); });

Hi @matjazp, thanx for your reply and explanation. I really did not use the FieldtypeSelect module and could delete it without any disadvantage. I started with PW ten years ago with two projects. After a learning phase and a lot of help from this forum, everything ran without problems until I decided to update this website http://malabu.de. I found some old modules and problems with the current PW version. And again I found help. So I have to say thanx to this beautyful forum and this great CMS. Günter

Great! $modules->getConfig('MarkupPagerNav'); Thanks for this push in the right direction!

Hi @elabx, thanx for your reply. I tried to disable module compilation and template file compilation in the /site/config-file, but that made the whole site unreachable. The file-compiler log grows and grows, and meanwhile I'm even not able to delete the about 10 000 entries. It shows again and again: Compiled file: /site/modules/FieldtypeSelect/FieldtypeSelect.module I am completely at a loss.

I've only played around with the new admin theme and haven't committed to it yet. That was one thing I noticed as well and I feel the color difference in the original theme definitely makes it easier to visually separate nested fields.

Serious question: If it's not too late for anything, then why is feedback like this not considered to be helpful? What I tried to point out is that when using UIkit like explained in their docs, then we would not have these issues at all. To change the primary color all you'd have to do is this: @global-primary-background: red; Then all primary buttons will use that color. All progressbars will use that color. All UIkit components will use that color. And any component that they might add in the future will use that color as well. Which means that any developer in the world can not only use what the core uses but anything UIkit has to offer. Framing that as "features that ProcessWire traditionally did not offer" is what I consider as not being helpful. We, on the other hand, are using thousands of overrides at the moment. Anything that Diogo didn't think of will possibly cause issues. Cause frustration or ugly fixes on our side and cause Github issues on your side and I think your time can be spent better. Seeing reno green shine through tells me that the new theme must be extending (if you don't want to call it overriding) the reno theme and not the base theme, that I carefully split apart from the reno theme in 2021 to make exactly that possible: Properly extending the base theme without applying layer by layer of overrides. Exactly like you mentioned with PHP classes. What I see in the new theme does not match what I read in your announcements and explanations, sorry. I consider that to be a very valuable feedback for anyone that is open to hearing it. Unfortunately for many reasons I got the impression that it's too late for such input. And I understand that this is a difficult situation. That's why I apologised. It does indeed not help if anybody complains about fundamental issues if it's not possible to change them. I get that and as I said I'll try to be more constructive with that situation. But please don't pretend that it's not too late for anything and that we are at an early stage in the process. This feels dishonest to me on my cost. Obviously I also do not think that micro-managing a professional designer would be helpful and that's not what I have been suggesting. I just don't see anything wrong in asking the community for input upfront. At least that's what I did with my calendar module and I think it was a very helpful and pleasant process: What features should a PW calendar module have? The community was just as great as it has always been. It does of course not mean to ask the community to decide every button's color. But it might help to reduce the risk of having blind spots. It might make the process even more creative, not less. It might help in making the community feel heard, accepted and valued. And it might even help in saving development time by cutting on features that sounded/looked cool at first but raised serious concerns in the community. And one more thing about the term "secret": You have some good evidence here. It was not my point though, and it might have been more constructive to ask me what made me feel like that than proving me wrong. I know I'm not the only one feeling like this. English is not my first language, but that sounds ironic to me and I'm not sure if it is the best time for being ironic after I apologised. I'm not sure how a user will feel when using dark mode for everything and some pages suddenly appear in light mode, but at least this means that it's no longer a go/no-go decision when somebody wants to use one of my modules, so thank you for that. Do i interpret this correctly as that darkmode is not any more considered to be experimental and is here to stay? --- @ryan please be reminded that I still very much admire what you have built and achieved. I'm sorry that you have expected a different feedback. But I hope it's ok to not only cheer if we like what we see but also raise our voice if we don't. Thx and all the best