Jump to content

MarkE

Members
  • Posts

    682
  • Joined

  • Last visited

  • Days Won

    7

MarkE last won the day on September 7

MarkE had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

MarkE's Achievements

Hero Member

Hero Member (6/6)

346

Reputation

  1. Looks good @ryan I’ve already built 2 apps with invoicing as part of them. The approach is pretty similar. I used hanna codes quite a bit for the invoice layout. To my mind, the important thing would be the ability to integrate into a wider app (which might, for example, handle products and stock levels). In some ways I think the profile approach is better than a module for this. However, if someone wants to use it in an existing app (or one already in development) we once again hit the issue of “migrations” about which I know there are various views. Ideally you need a way to incorporate the code and database components into another project.
  2. Yes and no. I couldn't get your code to work. It seems like you need to put the matching <div> in the php file, not the latte file. So, with your example (where<div id="foo"> matches an id in _main.php) // home.php <div id='foo'> <?= $rockfrontend->render("sections/home.latte"); ?> </div> // sections/home.latte <h1>{$page->title} - foo!</h1> Afterthought: However, it seems that Latte makes markup regions all rather unnecessary and confusing - easiest just to directly render latte files from _main.php. For flexibility, I have // In _main.php: <body> <?= $rockfrontend->render("layouts/main.latte"); ?> </body> // In layouts/main.latte: {include "$page->template.latte"} // plus whatever else you want (sections etc) // Then whatever in the template latte file Unfortunately, it seems you still need the php template file, even if empty. It would be nice to get rid of that...
  3. Just starting to use this and I like what I see 😀. I have always used markup regions for my front-end rendering and am wondering what is the best way of making these play with RockFrontend and Latte (if at all)? I like the renderMatrix method, but it just renders flat html when the repeaters have structure (depth), so I built an analogue - renderMatrixIndented, which renders the structure via <div> tags. Here is some code (which lives in my custom page class) in case it is of any use. /** * Render RepeaterMatrix fields with depth * Each level receives a div with a class name equal to the item type * @return string */ public function renderMatrixIndented($items, $vars, $options, $rockfrontend) { $out = ''; $depth = -1; $divCount = 0; foreach ($items as $item) { $field = $item->getForField(); $type = $item->type; $depthChange = $depth - $item->depth + 1; if ($depthChange > 0) { while($depthChange--) { $out.= '</div>'; $divCount--; } } $out.= "<div class={$type} style='{$item->theme_style}'>"; $divCount += 1; $file = "fields/$field/$type"; $vars = array_merge($vars, ['page' => $item]); $out .= $rockfrontend->render($file, $vars, $options); $depth = $item->depth; } while($divCount--) { $out.= "</div>"; } // if renderMatrix was called from a latte file we return HTML instead // of a string so that we don't need to call |noescape filter $trace = Debug::backtrace()[1]['file']; if (strpos($trace, "/site/assets/cache/Latte/") === 0) $out = new Html($out); bd($out, 'OUT'); return $out; } No doubt this could be generalised somewhat. BTW, it also adds some styling to each item if it has a field 'theme_style' but that could probably live elsewhere. I am using this in a simple page builder where class names can correspond to grid areas.
  4. version 0.0.19 adds 2 new Measurement methods: baseMultiplyBy() & baseDivideBy(). You can use these instead of multiplyBy() or divideBy(), where it is expected that the result of multiplyBy() or divideBy() would be an unknown quantity. These methods anticipate that the result will be a BaseMeasurement and avoids unnecessary warnings
  5. Yeah great songs. But to bring order to the chaos, it must be JS Bach.
  6. Pretty much! The only difference is that I was using a page ref field for the template, rather than a parent.
  7. I was just starting to develop something similar, based on CSS grid, which I think is the right way to go. One thing my design has is “pro-forma” pages - ie pages with pre-defined layout and dummy content that you can use to create similar pages. This is an approach I have taken before for “standard letters” and works well. Not sure if that’s in your module @jploch, but I’m hoping I could easily add it. Anyway, I’ll hold off now and test yours, if I may. I have a project I was going to use which is a WP conversion with a simple theme, which I hope makes a reasonable test bed. I’ll also look into how well my (json-based) DbMigrate module plays with it.
  8. If you are a designer not a developer, then I would suggest trying to move a site from one CMS to another is a bit of an ask. If you are happy with the structure and just want to modify content, then you should be able to do that in ProcessWire without any particular technical or coding skills. If you want a new look and feel and don’t want to use a developer, then maybe start from scratch in WP, just copy and paste what content you need. That assumes that you are proficient in WP. I gave up on WP because, while it looks simple, the complexity goes up exponentially the more you try to do.
  9. I quite agree. BUT I think ProcessWire would benefit from a larger user group. Many (professional) developers are influenced by the critical mass of an open source solution - below a certain level and they are wary of being tied into a framework that may be going nowhere. For that reason, ProcessWire is often not chosen and an inferior, but more widely used, system is selected instead. The advantages that a page builder potentially brings are, to my mind: More users are attracted to PW. Some of these might be 'non-coders'. Equally, they may be people who can code (to some extent) but who just want to implement a simple site quickly (which might be enhanced later). A developer can off-load some of the work to a 'non-coder' who can focus on design aspects (this may be the client) However, the crucial point that @pwiredmakes is that the use of a page builder should not restrict the site further. The structure of ProcessWire is such that this ought to be achievable, but only if a page builder makes use of PW components in a transparent and modifiable way. There seems to be quite a bit of activity in this area, notably @Jonathan Lahijani's above and @bernhard's RockMatrix (still under wraps, I think), and it would be good to have a bit more visibility of the approaches used and how they meet these objectives. I have done a bit of thinking myself about how a page builder should look, but it's early days yet (and I don't want to re-invent the wheel). Ideally it would make use of standard PW components, but it would be opinionated to some extent (CSS grid and Tailwind seem obvious choices). Trouble is, most of the paths I have explored so far end up using RepeaterMatrix. Don't get me wrong, RM is a great field, but I don't think it's a great idea to have a page builder, which is designed to atrract new users, being dependent on a commercial module. P.S. Also, I think a page builder should allow for multiple themes, so that developers can easily add a new theme.
  10. That's a shame. Maybe an initial release would help 😉 At least some feedback might be useful.
  11. https://processwire.com/modules/app-api/ ?
  12. Technically, not a lot, since the generic QuickStart works well. The main reason would be for visibility. Someone installing ddev might be prompted to think about ProcessWire as a solution.
  13. I wonder if we could contribute a cms QuickStart for ddev. It would be nice to have ProcessWire listed there!
  14. Spot on @bernhard. Million thanks! But I'm still puzzled, because in the phpStorm data source definition, I have localhost and it works - if I change it to db, it doesn't work.
×
×
  • Create New...