Jump to content

bernhard

Members
 View Profile  See their activity

  • Posts

    6,268

  • Joined

  • Last visited

  • Days Won

    314

 Content Type 

Everything posted by bernhard

  1. bernhard

    Using Latte

    bernhard replied to Greg Lumley's topic in Dev Talk

    Maybe {$page->SEO|noescape} ?
  2. bernhard
    https://processwire.com/talk/topic/4452-reset-config-appendtemplatefile-for-certain-templates/
  3. bernhard
    Thx @heldercervantes that's interesting to see! What does the migrations menu item do or look like?
  4. bernhard
    This statement is true for almost any use case ? Back to topic: I like your idea! It would be handy for my workflows as well. I'm developing almost anything that I do in a modular reusable way. That's possible and almost as quick as doing it the regular way thanks to RockMigrations. But storing data for non-public data (pages that are not viewable on the frontend) is one of those things that are a little tedious to build. You always have to create a parent template and a child template, then link both together, etc... Though I'm not deep enough in the topic to know how exactly that could work. For example I've never used the ProfieldsTable module which sounds like it's doing something similar? At least for my case I'd also need the possibility to create custom tables, not only read them. Or is that exactly what the table field does and you are talking about only reading existing tables? Couldn't we build somthing that supports both needs? Just brainstorming/asking... ?
  5. bernhard

    Using Latte

    bernhard replied to Greg Lumley's topic in Dev Talk

    RockFrontend will have a render() method that can render latte files. In my setups the main markup file is PHP and there I just use something like this: <head> <?= $rockfrontend->styles('head') ->add('my/theme.less') ->add('foo/bar.css') ->render() ?> </head> <body> <?= $rockfrontend->render('sections/header.latte') ?> <?= $rockfrontend->render('sections/main.latte') ?> <?= $rockfrontend->render('sections/footer.latte') ?> </body> Then I have empty PHP files for each template so that PW knows that these templates are viewable on the frontend. Ugly, but that's how PW works. Latte docs show how you can render latte files here: https://latte.nette.org/en/develop
  6. bernhard
    The idea was that RockMigrations could save at least module config settings to yaml files. I'm still not a fan of putting migrations in general into yaml files, because the execution order of migrations can matter and that's not possible to do in yaml while it is possible to do in PHP. But for module configuration I guess YAML would be an easy thing. So one could for example could install tracydebugger, do all the necessary config and hit save. Then all developers working on the project could have the same debugger settings. That might be a good thing (for module settings that need to be consistent across all environments), but it might be something you don't want. Again that's a problem that is not easy to solve and that's the reason why I think it makes the most sense to write migrations by hand.
  7. bernhard
    Yeah I was just hoping you have some experience with it and have done the review before so I don't have to do it ?? Proper image handling is something on my list and it's definitely something that I'd want to have in RockFrontend. The goals is to have a module that makes all the tedious frontend tasks easier and more efficient. srcset would be a perfect example and image handling is on my list for quite some time now, but I don't even have experience with webp at the moment so I might not be the best person to implement such a feature ? Let's see what you guys think of RockFrontend once it is published and then maybe someone wants to contribute... Thx for the suggestions ?
  8. bernhard
    Thx @Pixrael I've seen those filters already. IMHO many of them are overkill: // why should I use this? {$page->title|bd} // if I can simply use this: {bd($page->title)} I don't want to add too much stuff that might be more confusing than helping. For example I also see no reason for this: // why this? <div {$page->featured_image->size(1180,320)|bgimage|noescape}></div> // and not simply that? <div style="background-image: url('{$page->featured_image->size(1180,320)->url}')"></div> The latter is much easier to control. Though there are some examples that could be a great timesaver, like this one: https://github.com/rolandtoth/TemplateLatteReplace/wiki/Additional-filters#srcset Do you have any specific wishes or experience with the other latte module?
  9. bernhard
    That was the important part of my questions ? My point is that it would be very easy to do something similar in the PW world, where a YAML-based config is replicated to the database. But in my opinion that's useless... I just got a new idea for RockMigrations, thx ?
  10. bernhard
    I forgot to ask: How many mails will be sent? Tens? Hundreds? Thousands? Sure a cronjob would be the way to go. LazyCron can be an alternative on a shared host, but might not be the best solution ?
  11. bernhard
    Why do you think that? This is just using PW selectors and maybe comparing dates ? Also sending mails is not complicated (using WireMail for example as you already mentioned). The complicated parts are IMHO: subscription management (what happens if ... and what if ... and so on ...) mail deliverability (not too hard but you need to be careful) mail layouts (responsive, different mail clients etc) ProMailer can help for subscription management I guess and for deliverability the easiest solution is to use some transactional mail provider. For layout you can have a look at something like MJML...
  12. bernhard
    That sounds awesome, but I can't really believe that it is as awesome as it sounds. For example, how would you create a module for craft that does the heavy lifting, but still gives you the freedom to apply changes. An example. Note that I'm using ProcessWire language and concepts as I don't know the equivalents in craft: What if you wanted to provide a blogging module. Let's say a blog post consists of a headline, a body text and a gallery. How would you do that in craft? Create all the necessary fields and pages via GUI and then push the yaml files to your repo? And then someone installs your module and has all those pages/templates/fields? And then what if this person wanted to add another field to the "blogitem" template? For example a date field, or an URL or an author (page reference field). How would that work in craft? What if he added all those things via GUI? Would that break the update possibility of the blog module? Or would an update overwrite those changes?
  13. bernhard
    Need a language switcher? <div class="..."> <a n:foreach="$languages as $lang" href="{$page->localUrl($lang)}" class="..." > {$lang->title} </a> </div>
  14. bernhard
    Yeah, looks like! Thx for remembering me about that ? https://processwire.com/talk/topic/22503-bug-report-get-user-language-in-hook-pagessaveready/?do=findComment&comment=193243
  15. bernhard
    I've updated my post yesterday, seems you didn't get that detail ?
  16. bernhard
    I guess you are adding the hook in init(). If you add it at ready() it will work. Init() is too early for the system to know anything about the user or the language... I think my explanation above is wrong - it works because of the way my language switcher for tracy works! I've updated the code which works for me: $wire->addHookAfter("/foo", function($event) { // first we get a fresh copy of the current user $user = $this->wire->pages->getFresh($this->wire->user->id); $lang = $user->language; // then we set the correct language to retrieve values $this->wire->user->language = $lang; // output to check results $title = $this->wire->pages->get(1)->title; return "user name = $user->name, language = $lang, homepate title = $title"; }); So you are right, the hook does not seem to have the correct language of the user by default. Which it should I guess. Maybe open an issue on github?
  17. bernhard
    Another nice one from today: Imagine you are on a blog overview page and you want to provide a link for your clients to directly add a new blog post (if they are allowed to): <a n:if="$page->addable()" href="{$pages->get(2)->url}page/add/?parent_id={$page}" > Add new blog-item </a>
  18. bernhard
    True, that's why some of my new modules will work on the frontend by default if the site is using RockFrontend for the frontend. Otherwise users will have to include scripts and styles the boring old way... I've done it similar on many many sites. But it did not feel right. Too much "foreach" and "if/else" in my templates... Also things look easy at first thought (using FilenameArray), but then you notice it's not enough... What if you wanted to add a custom property to your tag like "defer"? That's another if/else in your template. What about a cache busting timestamp? Another few lines and checks you have to do, because ProcessWire does not have a nice way to convert between paths and urls, which you need, because you need the path for filemtime() but the url for the html tag... What if you wanted to add a script only on several pages or page types? Another if/else (how many do we have until now?)... What if you wanted to use LESS instead of CSS? Another module, some more lines of code... What if you wanted to add all stylesheets of a folder, so that you can split your CSS into logical pieces and move components from one project to another easily? You'd need to add all those files to your main markup file manually... All that is solved by RockFrontend: <?php namespace ProcessWire; /** @var RockFrontend $rockfrontend */ $body = $rockfrontend->renderLayout($page); ?><!DOCTYPE html> <html lang="de"> <head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <?= $page->seo ?> <?php echo $rockfrontend->styles('head') ->add('theme/uikit.theme.less') ->addAll('sections') ->addAll('/site/assets/RockMatrix') ->addIf("theme/blogitem.css", $page instanceof Blogitem) ->addIf("theme/newsitem.css", "template=newsitem") ->add('https://use.typekit.net/xxx.css') // adobe fonts ->render(); echo $rockfrontend->scripts('head') ->add('theme/js/uikit.min.js') ->add('/site/modules/RockFrontend/lib/alpine.min.js', 'defer') ->add('/site/modules/RockFrontend/RockFrontend.js', 'defer') // when logged in rockfrontend will inject Alfred.js here! // don't remove this rendering block even if you don't add custom scripts ->render(); ?> </head> <body> <?= $body ?> </body> </html> And since I'm rendering the layout in line 3 (above the <head>) I can inject scripts and styles from any other file that is loaded for rendering.
  19. bernhard
    I'll release RockFrontend very soon that does exactly that. It will support LATTE for templates (if you want), LESS for stylesheets (if you want) and comes with zero-setup autoloading (both on the frontend and backend). And you can inject scripts from your modules: $rf = $this->wire->modules->get('RockFrontend'); $rf->styles('head')->add(__DIR__.'/mystyle.css');
  20. bernhard
    Using RockFrontend your code would be like this: <div class="header_navigation block"> <div class="header_language block"><?= $rf->render("partials/header_language") ?></div> <div class="header_navbuttons block"><?= $rf->render("partials/header_navbuttons") ?></div> </div> Which is the short version of this: <div class="header_navigation block"> <div class="header_language block"><?= $rockfrontend->render("/site/templates/partials/header_language.latte") ?></div> <div class="header_navbuttons block"><?= $rockfrontend->render("/site/templates/partials/header_navbuttons.latte") ?></div> </div> But you can also use latte's include: https://latte.nette.org/en/tags#toc-include What more could I say than I love it? I'll share more examples here in the thread when they pop up in my work. And I'll release RockFrontend very soon (just need to do the showcase video...) Just wait for RockFrontend ? Or see here: https://latte.nette.org/en/develop
  21. bernhard
    I don't know when I last found a tool for my daily work that had such a huge impact as Latte. The last one was ProcessWire I guess (which had an even greater impact of course, but still). Latte uses PHP syntax so you don't have to learn a new language! It plays extremely well with the PW API and it makes my markup files so much cleaner and easier to read and maintain I can't tell you. From time to time I stumble over situations where I'm once more impressed by latte, so this thread is intended to collect small latte snippets to show how one can use it. If you want use Latte for your ProcessWire projects you can either install it via composer or you wait some more days until I release RockFrontend - a frontend module that can render latte files and comes with several other nice frontend helpers ? ----- Breadcrumbs the Latte+PW way: <ul> <li n:foreach="$page->parents()->add($page) as $item"> <a href="{$item->url}" n:tag-if="$item->id != $page->id"> {$item->title} </a> </li> </ul> The cool thing here is that the last item (the page we are currently viewing) is NOT linked. The <a> tag is only rendered for all other items. Still the label of the link is rendered, because we are using n:tag-if and not n:if ----- Output an image, but only if it exists: <img n:if="{$page->yourimage}" src="{$page->yourimage->maxSize(400,300)->url}" alt="..."> Note that the ->maxSize() call will NOT throw an error even if you didn't upload an image! This is one of my favourite features of latte: Write the markup once and then add simple instructions directly within that tag. No more if/else/foreach chaos ?
  22. bernhard
    How would that concept work with multiple languages?
  23. bernhard
    I just wanted to mention that I hope that our new editor will still be a rich text editor and not a page builder (like the mentioned "article" editor) - imho we should not mix those two! I've done a lot of work and research in that regard over the last two years or so and I'm now very happy with my repeater based content builder. When I started I also looked at editor.js as the interface looked neat. But I couldn't even manage to build a single custom content element with it. It's an editor for JS artisans and not for PHP devs like me (us?). A repeater based content builder has the huge benefit that we can simply use all the existing fields that PW provides. If at some point someone created a new field that would most likely just work within a repeater. Having a new editor interface with a totally new storage concept would mean we'd need to build all those block's for the editor and we could not use them outside of it. What about Multi-Language? The example above shows a nice page builder, but I wonder how multi-language would work with such a field? In a repeater-based setup we can just install LanguageSupport and make those fields translatable. PS: Using a matrix based approach makes CKEditor fields usually super simple! Like this one where only bold text and links are allowed:
  24. bernhard
    The questions you are asking need a lot of experience and/or testing. It always depends on the specific use case or environment. In general plain DB tables are better for performance, but have the drawback that you can't directly edit them via GUI. Also querying might be a little more complicated than what we get from PW pages and PW api. PW pages on the other hand have the benefit of having a GUI built in and making it easy to manipulate data via API, use hooks, use PW fields (eg for storing images) etc.; Basically all the PW magic. The drawback is that they have a bigger footprint. The need more memory, they might not be as efficient as direct DB queries, etc.. That's one of the reasons why I built RockMigrations. You can do all that using the PW api and you'll find several examples for that. For example the blog module does it like this: https://github.com/kongondo/Blog/blob/a13af302af9e6ce1bcbbe623a36b8efc1a033763/BlogInstallWizard.php#L352 As you can see those things can quickly get complex... RockMigrations abstracts that logic and can be used to help you built modules that create fields, templates, pages etc... <?php $rm->migrate([ 'fields' => [ 'field1' => ..., // create field1 'field2' => ..., // create field2 ], 'templates' => [ 'blog' => [ // define fields of blog template 'fields' => [ 'title', 'field1', 'field2', ], ], ], ]);
  25. bernhard
    https://processwire.com/blog/posts/pw-3.0.173/ ?
×
×
  • Create New...