-
Posts
6,267 -
Joined
-
Last visited
-
Days Won
314
Everything posted by bernhard
-
Interesting need. I've stopped using MarkupRegions because it was more confusing than helpful for me. But you can use them with RockFrontend of course. RockFrontend does not care where the markup comes from and so does ProcessWire. So for example you could just render a latte file from your home.php file that holds the markup for the markup region and then in your main markup file (or any rendered LATTE file) you simply add that region and it will hold the content of the markup you put in home.php If that sounds confusing I'm sorry, but that's how it is when using markup regions ? // home.php <?php echo $rockfrontend->render("sections/home.latte"); // sections/home.latte <div id='foo'> <h1>{$page->title} - foo!</h1> </div> // _main.php <html> <body> <?= $rockfrontend->render('sections/main.latte') ?> </body> </html> // sections/main.latte <div>This is main latte</div> <div id="foo"></div> <div>End of main latte file</div> Does that make sense?
-
Maybe we could join forces and extend my module with a simple toggle (light mode/dark mode)?
-
Hey @flydev ?? great to see another admin style coming up ? Check out https://github.com/baumrock/AdminStyleRock/ to see how you can create a module for 1-click-install without the need to copy files! This is all you have to add to your module: https://github.com/baumrock/AdminStyleRock/blob/30c91c9832ac8bc54fa64fbee416919824a1983d/AdminStyleRock.module.php#L35-L53
-
No, I mean {$site->color = 'blue'} ? which sets the "color" property of my site module to 'blue' and later I can echo that setting (also in other latte files!): <h1 style="color: {$site->color}">foo bar!</h1> {var ...} does only define a variable in the current latte file. That is a latte thing. What I tried to show is how you can use regular PHP. ?
-
Hey @pmichaelis thx for the module. I've had some weird issues on my current project and tracked it down to the textformatter. Turned out that your module turned this: <p>xxx</p> Into that: <html><body><p>xxx</p></body></html> This is the fix that works for me: https://stackoverflow.com/a/22490902/6370411 I'll comment that on github if you want to fix this ? I don't think that the textformatter should add <html> and <body> to the markup, or was that intended?
-
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 ?
-
[Solved] datetime and multi-language support
bernhard replied to Laegnur's topic in Multi-Language Support
-
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>
-
Migrate PW website to Wordpress?
bernhard replied to orchardheightsdental's topic in General Support
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
-
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...
-
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: Quickstart for RockMigrations ?