bernhard

// site/migrate.php $rm->installModule('YourModule', [ 'fooSetting' => 'fooValue', 'barSetting' => 'barValue', ]); See https://github.com/baumrock/RockMigrations/blob/main/profiles/default.php for inspiration. Please let me know if anything is unclear and can be improved.

Hi @daniel_puehringer What about just populating the cache via cronjob and don't care too much about the timings? The cronjob would run every 24 hours so it should be enough to just overwrite the cache when the cron runs: // in the cronjob $data = ...; // get data via WireHttp $wire->cache->save('your-cache-name', $data); // purge procache // https://processwire.com/api/ref/pro-cache/clear-page/ $procache->clearPage($your_cached_page); And in the template you just output that value: echo $wire->cache->get('your-cache-name'); That should be everything you need. To make it more robust you could create a little module that has a method that fetches data: <?php namespace ProcessWire; class Site extends WireData implements Module { public static function getModuleInfo() { return [ 'title' => 'Site', 'version' => '0.0.1', 'summary' => 'Site Module', 'autoload' => true, 'singular' => true, 'icon' => 'bolt', ]; } public function init() { // make this module available as $site API variable $this->wire('site', $this); } public function fetchYourData() { $data = ...; // get data via WireHttp $this->wire->cache->save('your-cache-name', $data); return $data; } } Then the cronjob gets easier: $site->fetchYourData(); $procache->clearPage($your_cached_page); And the template file get's more bulletproof, because if the cache is not available for whatever reason it will go and get it from the remote site: echo $wire->cache->get('your-cache-name') ?: $site->fetchYourData();

v2.19.0 comes with a new handy javascript snippet that can help, for example, to create to-top-links that slide in after a certain scroll position: If you have ideas for improvement let me know!

Thx to feedback and a good find from @Stefanowitsch v2.18.0 also copies .css.map files over to the assets folder, which is helpful if you are using one of the postCSS features like rfGrow() or rfShrink() You are not using them yet? You are missing something! They are so great ?

Nice! https://drawsql.app/teams/baumrockcom/diagrams/processwire

I knew that was spam. Interesting conversation nonetheless ?

If you are faster with another system then of course it's likely better to go with that ? I'm just trying to be fair to PW so I tried to challenge your statements as I think they are at least partly not correct or at least incomplete ? "others bring better functionality" is just an opinion and you don't bring any arguments for that. Didn't see that part, sorry. Sure. And almost everytime I ended up thinking that I'd be much faster with PW. But obviously that's the tool I know the best. Sure, agree on that. I'm just not on line with the arguments you brought up against PW ? Not saying PW is ideal for that (though it can be in some situations). Just tried to be fair ? I mean... you are right that sometimes it's not the easiest thing to adjust the backend menu to your needs, but what I wanted to say is that you should not forget that it might not be easier/faster to build everything on your own that you get in PW by default... I think what is really missing for building a CRM with PW is a good data listing tool. I've built RockGrid for that but it's far from perfect ? The other big missing thing would be migrations, but there's RockMigrations and that is in my opinion a lot better than what you get with Laravel!

Thanks guys, I've added a config setting for the z-index of the topbar and changed the default from 99 to 999 ?

I'm not saying anyone is right or wrong, but I want to add: You can always build everything (the backend/GUI) on your own just like you have to when using any other php framework if you think that would be faster ? Nobody holds you from using PW in a traditional way. You can create DB tables and use SQL to query the data. Sure. Every pro comes with cons. PW's database system is built to support all the great flexibility and the ease of use via the API that we all love (I guess). If creating and restoring things from a single DB table is a priority for you, why don't you store all the data in a single table that can easily be restored? If the answer is that you would lose all the great features of PW (like page reference fields etc) and you know all the things that you'd need to build on your own in other frameworks. But I have the best knowledge about PW obviously so I might be wrong when it comes to judging other frameworks ?

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.