bernhard

The whole thing about template engines is to avoid PHP ? LATTE is different in that you can still use PHP (which I think is great!), because it actually compiles its templates to regular PHP files. So you can do a lot from within LATTE files, but not everything. So it depends what you want to do? You can't use foreach, if, else and such as PHP syntax. But for these things you have the latte equivalents and n:attributes. If you need lots of PHP in your template file you should maybe create a custom page class and put your PHP code in a dedicated method there, that you can then reference in your latte file: <p>{$page->outputSomething()}</p>

To debug such things TracyDebugger is extremely helpful! You could have just dumped $page->hero_items to the debug bar: bd($page->hero_items) ...and you would have seen what $page->hero_items was and why your if/else did not work ?

Thx to @gebeer we now have support for repeater fields in the new version of RockMigrations ? If you find any other features that have been implemented in RM1 that are not yet in RM2 please let me know or even better create a PR ? Bumped version to 2.0.0 as I just realised that this version number fits better to how I'm referencing RM1 and RM2!

Thx! I'm happy to hear that ? This is a completely recursive multi-level menu using LATTE + RockFrontend magic that should get you started ? <ul class="uk-nav uk-nav-primary uk-margin-top uk-margin-large-bottom"> {* define block that is used for recursion *} {define items, $items, $first} {foreach $items as $item}{* loop all items*} {* define variables for inside the loop *} {var $active = $rockfrontend->isActive($item)} {var $subid = "tm-menu-".$item->id} {var $numc = ($item->numChildren() && $item!==$first) } {* list item markup *} <li n:class="$active ? 'uk-active'"> <a href="{$item->url}" n:attr="rf-toggle: $numc ? '#'.$subid"> {$item->title} <svg n:if="$numc" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" aria-hidden="true" role="img" class="iconify iconify--tabler" width="20" height="20" preserveAspectRatio="xMidYMid meet" viewBox="0 0 24 24"><path fill="none" stroke="currentColor" stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="m6 9l6 6l6-6"></path></svg> </a> {* list for child-items *} <ul id="{$subid}" n:if="$numc" class="uk-nav-sub" {!$active?'hidden'}> {include items, $item->children()->prepend($item), $item} </ul> </li> {/foreach} {/define} {* now include the block for the first level of items *} {include items, $home->children()} </ul>

https://www.google.com/search?q=site%3Aprocesswire.com+reset+password https://processwire.com/talk/topic/26189-reset-admin-password-or-add-superuser-rol/?do=findComment&comment=217769

PM: "can we have the separator line not only on top of each list item but also after the last one?" <div n:foreach="$block->steps() as $step"> {$rockfrontend->render('img/hr.svg')} <div>...</div> {$rockfrontend->renderIf('img/hr.svg', $iterator->last)} </div> The $iterator is available automatically in LATTE loops! And it plays perfectly together with renderIf() ? See https://latte.nette.org/en/tags#toc-iterator

Thx @zoeck that's also fixed in the latest version ?

Nice ? How does this work? Can you reuse my snippets?

In RepeaterPage on line 114 it tries to access the property "name" of some object. So you could do this one line above: if(!is_object($yourObjectVariable)) bd(Debug::backtrace()); // or this if(!is_object($yourObjectVariable)) throw new WireException("should be an object"); // or this if(!$yourObjectVariable instanceof Wire)) throw new WireException("should be instance of wire"); The backtrace should then maybe have some insights for us...

Thx @zoeck I've pushed a fix for this, please check v1.6.9

@zoeck what is line 1282 of your version of RockMigrations? I guess it's a Windows issue as stat for "C" failed? Maybe I just forgot to do a normalizeseparators somewhere...

Thx @MateThemes it's fixed in v1.6.8 PS: Why is RockMigrations placed in the "MagicPages" folder? Shouldn't that be "RockMigrations"??

Hey @adrian I've built a module that provides a ->log('my data') method. In that method I check if tracy is installed and if so, the ->log('my data') call will not only write data to a logfile but should also dump that data to the tracy bar. That works of course, but the log now shows that it was called in MyModule.module.php instead of, eg _main.php Can I somehow tell the BD call what it should write here? Of course I could just do the bd() in the referencing file, but my ->log() method does more than just dumping data to the bar. Thx

Definitely ? There are some methods in v1 that are not (yet) in v2 - so if you find one that we need in v2 let me know. Though one reason for the switch was to get rid of many old concepts/methods that I did not use any more. And also to streamline debugging and error messages. In v1 some methods threw an error if something went wrong, others returned silently. In v2 this is streamlined and every method has a second parameter to make it return silently if that is what you want (eg when deleting a previously added field which would work on the first run of the migration but on all following would throw a log "field xx not found").

Thx for the feedback @dotnetic I put that into the video for everybody to see (realise) that it's really just one click to start using migrations. No other magic that needs to be done or has been prepared only for the video. Also the migrate.php file is created on install, so I thought that is an important thing for everybody to see who is not familiar with RockMigrations ? Thx, happy to hear that ? IMHO it is not only the best tool for migrations in ProcessWire. I've watched several videos about other migration tools in other CMSs and IMHO what we have in our PW world is much easier to use and sometimes also more powerful! The API based approach turned out to be a very reliable technique and it feels so much more natural to just add migration instructions to - for example - the migrate() of a pageclass than writing single migration files with an upgrade() and downgrade() somewhere and then end up with multiple files where you have no idea what they do (unless you inspect every single file). In RockMigrations you see what it does at first sight. And you get GIT diffs when anything changes. @netcarver do you still want to use file-based migrations or have you already changed your mind? I mean... you can also do that with RockMigrations - it's just not what I'm doing but that does not mean it's not possible or bad ? Maybe there are also good reasons for such an approach, so I'm happy to get input.

Hey @maetmar I'm not sure there is an easy way to add this to the module... The problem is that I need to use the render() method of the module somewhere to make a _main.LATTE file work. But you can easily just use your _main.php file to just render a _main.latte file. I think the module could not make this process any easier, because at least you'd need to adjust the setting of $config->appendTemplateFile which is the same amount of work as just adding "echo $rockfrontend->render('_main.latte')" in _main.php ? Does that make sense?

New video is out ? I hope it helps to get started with RockMigrations quickly! Feedback very welcome - it's really not easy to do videos about such complex topics, so if you think something is missing let me know! Happy to hear that @netcarver ?

New video is out: Quickstart for RockMigrations ?

That's of course true, but it would still be interesting to hear. For example if the reason is that the ProcessWire page is slow and a WordPress site would be faster, than that would be a wrong assumption and making the ProcessWire site faster would be maybe two hours of work while migrating the site to WordPress would easily be multitude of that... 23.4MB for the homepage is really not a good value and just by optimising your slider images (which should be as easy as using $img->maxSize(...)->url instead of just outputting the image in its original resolution via $img->url what your site is doing) you are able to speed up the site significantly. Then purchase and install ProCache and your site is insanely fast. That might be all you need. Because I think the design is nice and it also looks nice on mobile. So why throw that in the bin? If there are other reasons then these optimisations might be irrelevant of course. So it would be nice to hear your reasons ?

Thx to @gebeer I have now set up my VSCode to format my code in PSR12 on save ? It's very easy to get if you know how and if you have Intelephense installed (which I'd highly recommend). Simply copy that to your user settings.json: // code formatting on save "editor.formatOnSave": true, "editor.defaultFormatter": "esbenp.prettier-vscode", "[php]": { "editor.defaultFormatter": "bmewburn.vscode-intelephense-client" },

@netcarver please check v1.4.0 ? There was a wrong example in the readme having old RM1 syntax. But I've updated RM2 to use that syntax too!

Hey @netcarver sorry for the troubles!! Is the file called migrate.php ? It looks like it should work! The only think that I don't do is strict_types=1 - maybe that causes issues? Don't know anything about that. Do you have tracy installed? Then you can inspect the logs panel and you should see everything that RM did. And you see if it did something, because if there are no changes or your file is not watched then changes will not be applied... Yeah this is part of the MagicPages features introduced 2 weeks ago. It creates fake pages in the trash to make sure it can load those pages on init() and ready() and trigger their init() and ready() methods to attach hooks. I'm not happy with that solution yet and it introduced some problems on some of my projects, so I'll fix this as soon as possible! Meanwhile you could just use an older version: https://github.com/baumrock/RockMigrations/archive/742f1fab8c727b3892835bb43d573e4f5aa7be0d.zip

Could you pleas tell us why you want to do that to get a better understanding of the context? Also, what do you mean by "a large set of pages"?

PS: One goal of the module is to be "zero-setup" and that's why I think some things should be enabled by default. But an option to disable them is of course valid. As another goal is to be "progressive" or "unobtrusive".