bernhard

Hey Adrian I'm working on another SSE feature and got an error from Tracy invoking the class destructor: Adding this on top of the method fixes it for me: if (!$this->wire('input')) return; Not sure if that could have any side-effects? If not, could you please add that check in __destruct ?

Update: Seems that the compiled CSS has a culprit: .gridImage:hover labelself__trash:hover{display:block;color:#e83561;background-color:white}.gridImage__edit Any ideas why it compiles to "labelself" ?? Is that an issue with the compiler? Can we modify the SCSS to fix this?

The module originated from an idea/discussion in this thread. I hope that helps to see more PRs for improving the PW backend ? https://github.com/baumrock/Scss Watch core files When working on PRs for the ProcessWire backend you'll notice that the core ships with several SCSS files and the corresponding CSS files. To make it easy to work on the SCSS files without the need of adding complicated build tools to your project you can simply install the Scss module and add the following in /site/ready.php $modules->get('Scss')->watchCore(); Now your SCSS files will be watched for changes and once you change something and reload your page you'll get the new CSS on the fly and can commit both changes ?

Would be great if anybody could tackle this. Meanwhile I've created a new module that does the SCSS compiling on the fly ? Scss Module to compile CSS from SCSS Watch core files When working on PRs for the ProcessWire backend you'll notice that the core ships with several SCSS files and the corresponding CSS files. To make it easy to work on the SCSS files without the need of adding complicated build tools to your project you can simply install the Scss module and add the following in /site/ready.php $modules->get('Scss')->watchCore(); Now your SCSS files will be watched for changes and once you change something and reload your page you'll get the new CSS on the fly and can commit both changes ?

That happens to the best ? Regarding the editor: @gebeer showed me how he uses vscode prettier to format his code PSR12 compliant automatically on save. I'm using that now for all my work and that obviously messes up with all the core files, which is really annoying when working on PRs for code of others. Also @dotnetic and I had similar issues on his PRs for my modules. Turning off this magic in my IDE everytime I work on 3rd party files is not an option though. And if you forget it, then you are pissed! Because you'll have a totally reformatted file and the "undo" feature does not help you because you need to save the file after undo, which will apply the changes again (unless you really change all the auto-formatting stuff which will be stored in many places eventually). The solution: I've downloaded Atom solely for editing 3rd party files. Without any magic applied. Without it changing spaces/tabs etc. Works great! I can edit files in atom and see the changes in VSCode and can then commit the changed files easily ? Maybe that workflow might be helpful for others as well. You've been a hero member for me for a long time ? I like that screenshots @Jan Romero so is anything missing for a proper PR? The CSS is updated manually because I try not to mess with stuff that needs build steps. Same here. But I have an idea...

I could sleep well with that risk ? That would be great in terms of getting the PR done but not great for learning how to properly do PRs that need changes to the admins CSS ? Thx! I'm not sure, but are those buttons visible to everyone? I think the user needs permissions for them? Obviously for superusers they'd always be visible but I think as soon as a user is allowed to upload an image he/she should also be able to download it ? Thx everyone for the help/input!! ?

Cool @AndZyk do you have a screenshot?

Nice to know nonetheless for a mac newbie ? But today I had an SVG that was not displayed so your proposed solution would also not work I guess ? My request is also an attempt to get more contributors to PW and to get more PR's for little and easy to add things ?

Yes, but the point is that we need to do the modifications in SCSS, then compile the CSS and then ship BOTH files with a PR ? Of course we could hack the CSS file, but that's not a PR then, that's a hack. Edit: @psy and @3fingers sorry I added the request to my message. That got lost while editing the post title ?

I'm asking for someone to create a PR (or help me create a PR) for adding a new feature to the PW backend image field. See this mockup which adds a "download" icon to the top right corner of the image preview: Why is that a problem?? Have you ever had the need to download a file that was uploaded to the PW backend? Then you know that this would be a helpful addition. The problem with the "click on the image, then on the popup click on "save image as"" is, that some SVGs simply don't preview (maybe that's another thing we should create a PR for...). And no preview, no download. And even if the preview technique works --> that's too many steps for simply downloading the image! --- I've done some research and found that the markup is defined in /wire/modules/Inputfield/InputfieldImage/InputfieldImage.module --> so that's the place where the markup of the download icon should go. Easy. No problem so far ? The problem that I faced is that the styling is done in an .scss file where I don't have any experience. Also I don't have the frontend tooling to convert that into a css file. I think it should be easy to do though if you have some experience in that field. And of course for a proper PR we need to modify both the SCSS and the compiled CSS so that everybody that downloads will have a working version and that we make sure that future modifications to the SCSS file don't overwrite our changes. I think it's an absolutely necessary addition and this bugs me for very very long time. While it is for sure a great module, installing AOS solely for this reason is no option as I had several issues with the module that bugged me even more and cost me a lot of time when debugging... Also, I think that should not be a module, it should be part of the core. And we should make it as easy as possible for ryan to add it ? I can help with creating the PR if you need ? Who can do that for the community and help improve PW? ?

Hi @gornycreative it's used in a production project but I don't have it where I want it to have. And I don't have use for it right now, so it's nothing to happen soon.

You could also create pages that only have the code field and then reference as much snippets as you want with something like [code=123] where 123 is the page id. Or you use https://processwire.com/talk/topic/18289-processmention-forum-mentions-style-page-link-autocomplete-for-ckeditor/ then you could even include code snippets without any "coding". Or you use RepeaterMatrix to build a pagebuilder like experience.

You could also use this if I'm understanding you correctly:

Another HUGE THANK YOU to @gebeer for another PR that improves the downloadModule() method ? https://github.com/baumrock/RockMigrations/commit/9e82e117a43c77cfb94a55c14b822bc627e5649a

Do you have a reference for that statement? ?

Thx ? Yeah that's the usual way of doing migrations. I started like this at the very beginning, always creating a file with an upgrade() and a downgrade() method. But the declarative syntax is just so much better! It's easier and a lot faster to write (develop) and it's easier to read (understand) and it's also a lot easier when looking at git diffs: You instantly see what I did here: Renamed the field constant from field_persons to field_personimages and added the field_personmatrix below the field_footermenu. And you can simply go back and forth in time by using your IDE: You could do that. The easiest way is to put everything into migrate.php; It's the same as with hooks. Where do you place your hooks? All in ready.php? Maybe you started like this. But likely you'll not do so any more and have most of them in dedicated modules where you bundle things that belong together. As you said that has the huge benefit of making things reusable. Since I've adopted that approach I'm developing faster than ever before. But to get started just go ahead with migrate.php ? Regarding your question about one file for fields and one for templates. You can do so. It's maybe a matter of preference. But I prefer to put everything in modules or pageclasses. Let's say we create a blog. We need a "blogitem" pageclass and that pageclass uses fields "title", "date", "content": <?php namespace ProcessWire; use RockMigrations\MagicPage; class BlogItemPage extends Page { use MagicPage; public function migrate() { $rm = $this->rockmigrations(); $rm->migrate([ // field migrations 'fields' => [ 'date' => [...], 'content' => [...], ], // template migrations 'templates' => [ 'blog-item' => [ 'icon' => '...', 'fields' => [ 'title' => ['columnWidth' => 70], 'date' => ['columnWidth' => 30], 'content', ], ], ], ]); } } Do you understand what it is doing? At first sight? Or would it have been easier if the migrations lived in fields.php and templates.php ? Also a thing to keep in mind is that sometimes the order of execution matters. And that's easier to handle if you place your migrations in places that belong logically together. That situation often arises when I'm writing migrations for parent/child template relations. The concept is as follows: Have a master module (I recommend having a Site.module.php for every project and the default migrations profile does that for you ? ) Load pageclasses from the master module (eg BlogItems and BlogItem) Trigger migrations in every pageclass (RM has helpers for that, see https://github.com/baumrock/RockMigrations/wiki/Ship-your-Module-with-Custom-Page-Classes ) That takes care of creating all fields for the template and adding fields to the template (like the example above) THEN set parent/child relationship (both templates need to exist before we can set this relation!) This makes the backend now that if you create a new page under "BlogItems" you are only allowed to add a single "BlogItem" Does that make sense so far? RockMigrations runs on every single request. Then it checks all the files that have been added to the watchlist (migrate.php is added by default, others can be added via $rm->watch(...)) and it will run the migrations for every file in the watchlist that has been changed since the last run of migrations. So if you had 30 files watched and you change one (let's say "BlogItem.php"), then only migrations of this file will be migrated. All others will be skipped. You can inspect that easily via the tracy logs panel where you see what is going on and in which order: Now if you combine that with RockFrontend, then you get instant reloads of the backend and therefore instant migrations while you code. So great, you have to try it! If you run migrations from the cli or you do a modules::refresh then all migrations are run (just in case the watcher does not catch up a file or something goes wrong): If you still have any questions let me know ? Also I'm happy to do consulting via online meeting if you have questions specific to a project (or want to support me and the development of my modules).

Hi @sebr , thx! Do you think you can provide a PR with a working solution?

Have you ever had a hard time setting the values of an options field via API? Grab RockOptionsAPI ? https://github.com/baumrock/RockOptionsApi RockOptionsApi ProcessWire module for easy manipulation of option-fields via API $page->getOptions('yourfield') ->add('foo') ->remove('bar') ->save(); Readonly options field renderer By default options fields that are set to readonly via the locked collapse state only show selected options and hide other available options. That might not be what you want. Here is an alternative that turns this: Into that: Simply call $form->readonlyOptions('yourfield') in the ProcessPageEdit::buildForm hook or when using MagicPages in the editForm() method: $wire->addHookAfter("ProcessPageEdit::buildForm", function($event) { $form = $event->return; $form->readonlyOptions('yourfield'); });

You can use the new getPageListLabel() method of custom page classes to mimic a table-like list: <?php namespace ProcessWire; // placed in /site/classes/BasicPagePage.php class BasicPagePage extends Page { public function getPageListLabel() { return "<span style='display:inline-block;width:200px;outline:1px solid black;'>{$this->id}</span><span style='display:inline-block;width:300px;outline:1px solid black;'>{$this->path}</span>"; } } Brilliant new feature ?

Hey @Richard Jedlička thx again for your great module! I'd have a request: Would it be possible to add a second icon to the template edit button on the page editor so that when clicked it opens the corresponding file in the IDE? The link could easily be taken from tracy settings and the filename is easy to get via ReflectionClass: $r = new \ReflectionClass($page); db($r->getFileName()); Similar to the field edit links there could be a second icon on hover that, when clicked, takes you directly to the PHP file of the custom page class that is responsible for the currently viewed page's template ? What do you think?

Hey @fruid have just been working on logs on another module. This is how you can prune the logs to a given number of bytes: $this->wire->log ->getFilelog("rock-mail-logger") ->pruneBytes(2000); This will prune the log to 2000 bytes (which is obviously very little just for testing).

Thx @fruid for the clarification. First of all how many emails did you send to get a 10GB logfile?? The logger logs quite a lot (headers etc) but I thought better to have than to miss it. I think the easiest way to do the cleanup would be to do the cleanup whenever a new log entry is created. That should be really easy to do using https://processwire.com/api/ref/wire-log/prune/ So you could add a config setting to the module that holds the maximum number of days the log should be kept and everything should work fine. This might also be a good idea regarding gdpr or similar regulations. That only depends on your server setup. You could also create PHP scripts that have root access to your server. It only depends on the permissions you give to PHP (for example to use exec()) and to the user that runs the script.

I read your message as "thank you for your help". You are welcome. A better practice than sending massive amounts of spam emails and logging all of them without cleaning up the logs from time to time? Sending only necessary mails. And cleaning up the logs ?? Or a better practice than complaining about free and open source modules? Helping to debug things and then trying to add improvements and creating a PR ? You could for example add the option to cleanup the mail log automatically after x days or after y logged mails...

Just find the correct logfile in /site/assets/logs, rename rock-mail-logger.txt to rock-mail-logger-bak.txt and then create an empty rock-mail-logger.txt and see if that changes anyting in behaviour.

Hi @fruid I don't think that my module causes this as I'm simply using PW's logging features. You can try renaming the log to something different and using it with a subset of the real data. Then copy over junk for junk and see if/when the error starts to occur. Not sure if that's the right thing to do with 504 errors but that could bring more insights.