bernhard
-
Posts
4,573 -
Joined
-
Last visited
-
Days Won
183
bernhard's Achievements
-
No. I just tried it again: // home.php <?php namespace ProcessWire; echo $rockfrontend->render("home.latte"); // home.latte <div id="markupregion">home.latte</div> // footer.latte <div id="markupregion"> original content </div> <section>I am the footer</section> Neither PW nor RockFrontend care about where the markup comes from. You just need to make sure that your region content is above the region markup. This is what it looks like when disabling $config->useMarkupRegions: You can even do that. Not sure if that's something that should be added to RockFrontend though. I'll add an entry to the WIKI... Here it is: https://github.com/baumrock/RockFrontend/wiki/RockFrontend-and-Markup-Regions#advanced-setup -
MagicPages (eg HomePage.php) do now also load the related CSS and JS files (eg HomePage.js and HomePage.css) in the backend page editor 😎 And there is a new WIKI page about MagicPages: https://github.com/baumrock/RockMigrations/wiki/MagicPages Magic Assets If your page is a MagicPage it will load YourPage.css and YourPage.js files automatically in the PW backend when editing any page of type YourPage. Example: // /site/classes/HomePage.php // /site/classes/HomePage.css div { outline: 2px solid red; } // /site/classes/HomePage.js alert('You are editing the HomePage');
-
v2.0.4 improves deployment and thx to another 2 PRs by @gebeer docs and features of permission handling were improved 🙂
-
Yeah that's what I tried to explain. You don't need admin.less - you only need the module that adds the custom admin style in init() or ready() 🙂 Now that I'm writing I realise that one can't customize my style once the module is installed. Because it won't pick up the admin.less file as it's overwriting this setting to use the module's style. That might be an improvement 🙂
-
Sorry I don't understand 🙂
-
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?
-
Would be interesting to see the difference (before/after) 🙂😉 No. You can execute PHP code like {alfred($page)} or {bd('foo bar')} or assign new variables like {$site->color = 'blue'} but not much more..
-
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!
