bernhard

Hi @Stefanowitsch it should show this: I'm not sure about the logo there and am open to feedback.

$wire->addHookBefore("Inputfield(name=roles)::render", function (HookEvent $event) { $field = $event->object; $field->appendMarkup = " <div class='uk-margin'> <button class='ui-button' data-options='1'>Options 1</button> <button class='ui-button' data-options='2'>Options 2</button> </div> <script> $(document).on('click', '[data-options]', function(e) { e.preventDefault(); let options = $(e.target).data('options'); if(options == '1') { $('input[value=37]').prop('checked', true); $('input[value=38]').prop('checked', false); } else if(options == '2') { $('input[value=37]').prop('checked', false); $('input[value=38]').prop('checked', true); } }); </script> "; }); Just adjust name=roles to name=your_options_field and value=37/38 to value=your_option_id (inspect via devtools) Have fun ?

Hey @protro congrats and thx for sharing and for mentioning RockFrontend ? I'd love to add such features to RockFrontend, so if anybody has good suggestions please create a thread in the dedicated forum!

Sure, done! Thx for the input ?

Does anybody know how we can insert buttons with custom classes in TinyMCE ?? That's a VERY common need, eg to add "uk-button-primary" to a link that was inserted via the TinyMCE field. As @jploch mentioned the inline styles seem not to work on anchor tags ?

Your error tells you that the requested file does not exist. If the file exists, then it means that your provided path is wrong. You seem to include/render "partials/foo.php", but if you are already rendering/including a file in the partials folder, than from within that file you cant render/include "partials/foo.php" because that would look for "partials/partials/foo.php". That's why you just provide "foo.php" and it should work. If you use render() than you can RETURN something in a file and that will be returned to the place where you made the $files->render() call. If you do an "echo $files->render(...)" then it will echo the output. If you do $foo = $files->render(...); you can do whatever you want with $foo after that call. If you use include() on the other hand the code in the included file will directly be executed and nothing will be returned, so you can't use include() to populate variables with the content of a file.

Did you try this? echo $files->render('other-file-name.php');

Well then it's an issue with TinyMCE that has nothing to do with ProcessWire. I'd try to see if there is already an issue for it (https://github.com/tinymce/tinymce/issues) and if not I'd report it there and ask for help.

No, not all. Only all the things that should be the same across all your setups ? That's a small but important difference. You can still use the GUI if you want to. But that means that you need to apply those changes manually to all other instances of your project as well. The thing is: Those changes are really really easy once you get used to it. 90% of the time it's setting the 'label' property or the 'columnWidth' setting of a field and adding fields to templates. Using the snippets for VSCode is definitely a huge help. Without them creating fields would be a little pain ? If anybody knows how that feature can be ported to other IDEs let me know! But if something is very complicated using RockMigrations you can still use the old-school way of making those changes manually! For example you could create some fields on the remote system and create some pages, then pull the database changes to your local development and just add all the easy stuff to migrate.php PS: Many of the settings I do not know by heart as well. But it's most of the time quite easy to find them by hovering the inputfield: PPS: I'm quite sure that finding the setting and writing it to migrate.php is faster than doing that manually on local dev and then replicating that change on the live system. It get's even better once you use multicursor in your IDE to set for example 3 fields to 33% width!

Thank you guys for the input! I appreciate the explanations. ...and that's exactly the reason why RockMigrations exists. Or you write the things you do in migrate.php and just upload that file... $rm->createField('mynewfield', 'text', [ 'label' => 'I am the field that the client wanted to have', ]); $rm->setTemplateData('home', [ 'fields' => [ 'title', 'mynewfield', ], ]); Is that really too much to ask? Seriously. What is the pain here? Is it that you don't know the settings? That's why I added the code section to copy&paste. I'm not trying to convince you here. I'm trying to understand. I know it would be nice to have a "copy current field & template config" button. But I'm afraid it's not that easy and it would be a lot of work for me to build a good solution while it would be really easy for you to just learn the basics of RM and simply write some lines of code. (And not to forget: It would make you a better developer as you'll quickly become more efficient overall and you'll learn a lot about PW which would help in many other situations as well!) Let me know if you find something.

Hi @wbmnfktr thx for the input ? Well... That is something that should be possible as well. RockPageBuilder does already save field + template settings to YAML so that you can edit all content blocks via GUI and don't need to write a single line of migration code (as I think there are still many that are not comfortable with writing migration code). The problem with adding that to RockMigrations are the following: It would mean several hours of work to make that possible. And the benefit for myself would be non-existent, as I prefer to write migrations by hand as its faster and maybe more reliable. Making field + template migrations available via GUI + YAML I'm quite sure there will be some that want the same for permissions. And then for users. And then for roles... The list goes on. It would need a lot more testing to see if the YAML approach does really work out as expected. When writing migrations you instantly see if what you write leads to the expected result. If it does, then it's almost certain that on remote it will work exactly the same. When saving config as YAML that does not apply. But I'm quite sure that users will expect a smooth experience and they would be upset/angry if something didn't work out. I'd be more than happy to add support for that to RockMigrations at least for template and field settings. But I'm not going to do that in my spare time. If you see any chance how to get that funded I'm more than happy to work on it ?

Upate: I've created a video for you: Why do you want to do that? You don't need to ? Correct. That's why I didn't build it that way. // content of migrate.php @ 2023-01-01 // create the foo field and add it to the foo template $rm->createField('foo', [...]); $rm->addFieldToTemplate('foo', 'footpl'); // content of migrate.php @ 2023-01-10 // remove foo field and create bar field instead // "true" makes it "quiet" - if not set it will write a log on every // following migration that says "Field foo not found" $rm->deleteField('foo', true); $rm->createField('bar'); $rm->addFieldToTemplate('bar', 'footpl'); // content of migrate.php @ 2023-01-16 // refactor to array syntax // that's nicer because you can instantly sort fields on the template // in the example we add 'bar' on top of 'title' $rm->deleteField('foo', true); $rm->migrate([ 'fields' => [ 'bar', ], 'templates' => [ 'footpl' => [ 'bar', 'title', ], ], ]); https://github.com/baumrock/RockMigrations/wiki/Ship-your-Module-with-Custom-Page-Classes This is an advanced example.

@huseyin what happened to the project?

First of all thx for that and I'm happy to hear that ? It would be interesting to add things step by step and see when things start going wrong! Maybe you can share a test project so I can have a look. But I'd appreciate if you can find it yourself of course ??

@sz-ligatur I've tried, but I can't reproduce on an installation having RockFrontend + RockMigrations running.

Hi, that's an interesting one. Could you also check the value in different locations please. Eg in site/ready.php or in _main.php before anything else? Maybe that tells us something. Because I have no idea until now..

Thanks for educating me on how I should develop my free and open source modules ? I hope you don't mind that I went a different route and added a check if RockFrontend is installed or not. Everything works without RockFrontend now as of v.1.0.6 Thx for spotting and reporting that issue.

Hey @PWaddict thx for the report. I had a look and you just need to install RockFrontend to make it work. Not sure if we really need that dependency just for this single feature but as a quickfix that is what you can do ?

https://www.mailersend.com/ is also a good option and you can have a look at https://github.com/baumrock/RockMailerSend (no docs at the moment and not officially released yet)

Yeah it's a pity, but I still haven't found a good replacement for it ? tabulator.info has similar features but it's overkill for a simple tabular input..

Today I realised that one of my sites has around 13k rows in the caches db table (20MB in size): The site is powered by RockMigrations automatic deployment so the folder structure on the server looks like this: According to @adrian this issue has nothing to do with TracyDebugger, so I wonder if anybody of you has seen a similar problem before and can help me debug/fix this? Thx! PS: Is it maybe as easy as deleting all FileCompiler_ rows on each RockMigrations deployment? PPS: Seems like a possible solution, or does anybody see a problem with doing this on every deploy? PPPS: Ok found the other bad guy: ProcessJumplinks ? Before: 20MB Removed FileCompiler Cache: 10MB Removed Jumplinks Module: 3MB ?

Thx @zoeck https://github.com/nette/latte/issues/287#issuecomment-1377083605

Version 2.9.0 changes the syntax for repeater fields from this: $rm->createField("my_repeater", "repeater", [ 'label' => 'Test', 'repeaterFields' => [ 'title', ], 'fieldContexts' => [ 'title' => ['label' => 'foo'], ], ]); to that: $rm->createField("my_repeater", "repeater", [ 'label' => 'Test', 'fields' => [ 'title' => ['label' => 'foo'], ], ]); This might be a breaking change in your system so check before updating ?

Thx, that works! I'm working on my pagebuilder and have a mobile preview where the debug bar is a little disturbing I guess. But I might hide it via CSS so that it is still visible on desktop view, I'm not sure: Good to know how to disable the debug bar though - thx!