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
    What do you think about adding a feature to merge scripts and styles? Is that something we should have? Or is it even bad to have since HTTP2 can download multiple assets in parallel?
  2. bernhard
    Thx to another request by @wbmnfktr and issues that I had on my own project I've improved asset handling, autoloading and debugging in v1.13.8 It also adds a new method to prepend() scripts and styles (like uikit.theme.less in the example below). Adding something like addAfter('mystyle.css', 'theme.css') is on my list... A default <head> can now look like this (note all the html comments that should be quite helpful): <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"> <!-- RockFrontend SEO by baumrock.com --> <title>Home</title> <meta property="og:title" content="Home"> <meta name="description" content="Home"> <meta property="og:description" content="Home"> <meta property="og:image" content=""> <meta property="og:image:type" content=""> <meta property="og:image:width" content=""> <meta property="og:image:height" content=""> <meta property="og:image:alt" content="Home"> <script>let rf_livereload_secret = 'rDksCMGEMFs87mNq3WrTaVug1tfeldQ0r9L4kUkfqghS'</script> <!-- DEBUG enabled! You can disable it either via $config or use $rf->styles()->setOptions(['debug'=>false]) --> <!-- autoloading of default scripts/styles enabled - disable using ->setOptions(['autoload'=>false]) --> <!--rockfrontend-styles-head--> <!-- loading /var/www/html/site/templates/uikit-3.15.2/src/less/uikit.theme.less --> <!-- loading /var/www/html/site/templates/layouts/_global.less --> <!-- loading /var/www/html/site/templates/sections/footer.less --> <!-- loading /var/www/html/site/templates/sections/hero.less --> <!-- loading /var/www/html/site/templates/sections/job-footer.less --> <!-- loading /var/www/html/site/templates/sections/menu.less --> <!-- loading /var/www/html/site/templates/sections/rocket.less --> <!-- loading /var/www/html/site/assets/RockMatrix/matrix/FactsBar.less --> <!-- loading /var/www/html/site/assets/RockMatrix/matrix/IconBox.less --> <!-- loading /var/www/html/site/assets/RockMatrix/matrix/IconRow.less --> <!-- loading /var/www/html/site/assets/RockMatrix/matrix/PagesGrid.less --> <!-- loading /var/www/html/site/assets/RockMatrix/matrix/QuoteSlider.less --> <!-- loading /var/www/html/site/assets/RockMatrix/matrix/Spacer.less --> <!-- loading /var/www/html/site/assets/RockMatrix/matrix/Team.less --> <link rel='stylesheet' href='/site/templates/bundle/head.css?m=1660204105'> <link href='/site/modules/RockFrontend/Alfred.css?m=1660124218' rel='stylesheet'> <link href='https://use.typekit.net/zeg8qpc.css' rel='stylesheet'> <link href='/site/templates/sections/foo.css?m=1660207177' rel='stylesheet'> <!--rockfrontend-scripts-head--> <script src='/site/modules/RockFrontend/Alfred.js?m=1660123300'></script> <script src='/site/modules/RockFrontend/livereload.js?m=1660123300'></script> <script src='/site/templates/uikit-3.15.2/dist/js/uikit.min.js?m=1659941286' defer></script> <script src='/site/templates/uikit-3.15.2/dist/js/uikit-icons.min.js?m=1659941286' defer></script> <script src='/site/modules/RockFrontend/lib/alpine.min.js?m=1660123300' defer></script> <script src='/site/modules/RockFrontend/RockFrontend.js?m=1660203134' defer></script> </head> ? v1.13.10 makes sure that LESS is forced to recompile on modules::refresh
  3. bernhard
    As soon as you want to add fields to templates you need to work with fieldgroups, as fieldgroups are the thing that connect templates with fields. I think the fact that many modules don't use fieldgroups is that - as you have realised - it is not that easy to create fields/templates/fieldgroups via API as there is a lot of things you need to take care of and that are not obvious and make things tedious. That's only one example of what I said above. But there are modules that create fieldgroups, of course. For example here: https://github.com/kongondo/Blog/blob/master/BlogInstallWizard.php The frustration you are going through is exactly the reason why I built RockMigrations...
  4. bernhard
    I don't see that the docs say anything different: https://processwire.com/api/ref/page/parents/ You can use parents("status=1"), but that might also exclude other pages (like pages having errors after save). Or you do a foreach and check $page->isHidden() for every item.
  5. bernhard
    Ok I think I get the problem. You are using markup regions and I guess you put all the markup in your template file (like home.php or impressum.php or basic-page.php). The problem is that AFTER loading that file ProcessWire will load the main markup file (which is _main.php). That's because in config.php you have set a $config->appendappendTemplateFile = '_main.php' (which is the new default after installation). So after the markup you put in impressum or home PW will load _main.php and that's what you seeing at the bottom of the page.
  6. bernhard
    I don't understand what you mean. Which menu? You can change the markup for your site either in _main.php or in the template file that corresponds to the template of the viewed page (template home = /site/templates/home.php). I've recently done a video showcasing RockFrontend where I'm also working on the markup a bit. Maybe that helps you as well:
  7. bernhard
    v1.13.5 adds notes about installed profiles thx to issue report from @wbmnfktr
  8. bernhard
    Thx @wbmnfktr the issue is fixed in version 1.13.3 I've also added the first WIP version of seo support ? <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"> <?= $rockfrontend->seo() ->title("{$page->title} | My Company") ->description(function($page) { if($page->template == 'foo') return $page->foo; return $page->body; }) ->setValue('og:image', function($page) { if($page->template == 'boat') return $page->boatpic; return $page->images; }) ?> </head> Tags can easily be set and truncation is as easy as adding an integer to the tag {value:160}
  9. bernhard
    You can just edit the first post and prefix the topic with [solved] ?
  10. bernhard
    <?php namespace ProcessWire; class Hello extends WireData implements Module { public static function getModuleInfo() { return [ 'title' => 'Hello', 'version' => '0.0.1', 'summary' => 'Your module description', 'autoload' => true, 'singular' => false, 'icon' => 'smile-o', 'requires' => [], 'installs' => [], ]; } } Voila - that's a working module without fieldgroups! Here an example without using RockMigrations (I'm so happy I've not had to do this for a very long time...): <?php namespace ProcessWire; class Hello extends WireData implements Module { const name = 'hello'; public static function getModuleInfo() { return [ 'title' => 'Hello', 'version' => '0.0.1', 'summary' => 'Your module description', 'autoload' => false, 'singular' => true, 'icon' => 'smile-o', 'requires' => [], 'installs' => [], ]; } public function ___install() { // create new fieldgroup $fg = $this->wire(new Fieldgroup()); $fg->name = self::name; $fg->save(); // create new template $t = $this->wire(new Template()); $t->name = self::name; $t->fieldgroup = $fg; $t->save(); // create field $f = $this->wire(new Field()); $f->type = 'text'; $f->name = self::name; $f->save(); // add field to template $fg->add($f); $fg->save(); } public function ___uninstall() { // delete template and fieldgroup $tpl = $this->wire->templates->get(self::name); if($tpl) { $this->wire->templates->delete($tpl); $this->wire->fieldgroups->delete($tpl->fieldgroup); } // delete field $this->wire->fields->delete($this->wire->fields->get(self::name)); } } And using RockMigrations: <?php namespace ProcessWire; class Hello extends WireData implements Module { const name = 'hello'; public static function getModuleInfo() { return [ 'title' => 'Hello', 'version' => '0.0.1', 'summary' => 'Your module description', 'autoload' => false, 'singular' => true, 'icon' => 'smile-o', 'requires' => [ 'RockMigrations>=0.13.3', ], 'installs' => [], ]; } public function init() { /** @var RockMigrations $rm */ $rm = $this->wire->modules->get('RockMigrations'); $rm->watch($this); } public function migrate() { /** @var RockMigrations $rm */ $rm = $this->wire->modules->get('RockMigrations'); $rm->createField(self::name, 'text', ['label' => 'Your field label']); $rm->createTemplate(self::name); $rm->addFieldToTemplate('title', self::name); $rm->addFieldToTemplate(self::name, self::name); } public function ___install() { $this->migrate(); } public function ___uninstall() { /** @var RockMigrations $rm */ $rm = $this->wire->modules->get('RockMigrations'); $rm->deleteTemplate(self::name); $rm->deleteField(self::name); } } When not using RockMigrations you need to be very careful with everything you do. It throws errors all the time if something does not exist what you are trying to remove/delete or it throws errors if somethings exists that you are trying to create... It throws errors if the execution order is not correct. It throws errors if you try to delete a template that is used by at least one page, etc etc... RockMigrations takes care of all those things so that you can focus on what you want to do. And you don't need to always install/uninstall your module while developing. Refreshing your browser will fire the new migrations. RockFrontend can even take care of that as well... ?‍♂️ You're welcome: https://github.com/sponsors/baumrock
  11. bernhard
    This thread is intended to be a collection of useful tips and tricks when developing PW sites using the awesome DDEV development environment. First tip (and only issue I've had since almost a year) is how to prevent an endless redirect loop when using "force HTTPS" in htaccess: https://github.com/processwire/processwire-requests/issues/452
  12. bernhard
    I've just created a ProcessWire group for Austria to connect - Maybe someone wants to join ? https://www.linkedin.com/groups/9218659/ And maybe others want to create their own and share the link?
  13. bernhard
    I don't know. You didn't write what you are trying to do, so how should anybody be able to show how it can be done? RockMigrations was just an offer to make it easier (whatever you are trying to do). You don't have to use it of course and there might be a much simpler solution... Of course you don't need to use fieldgroups at all when creating a module. See the hello world module. And I guess no one here has a clue what you actually did and where the error occurs ? How did you create your fields? Via GUI? Via code? What code did you use... etc etc... As far as I know: Not really... That was discussed very often and has pros and cons.
  14. bernhard
    Big thanks also to @elabx, really great! I'll stop posting about new sponsors now but I still appreciate your contributions!! ?
  15. bernhard
    I've worked with a commercial product lately and all I could do was writing an e-mail to the support-team and then wait over a week to get a response. The PW-forum is not the worst option if one is needing help imho ?
  16. bernhard
    You can also look into the code. Many areas of ProcessWire have very nice helping comments in the top comments of the related file or in the php docblocks above the methods. Of course it would be nice to have resources that explain everything in an easy to understand way - but don't forget that we are talking about an open source and free product... The docs of RockMigrations unfortunately are at the moment a bit... weak ? The sentence means that you can lookup all the properties that you need in the "RockMigrations Code" field in your GUI once you have created your field/template. RockMigrations offers an as-easy-as-it-can-get API for all the necessary steps that you need when building reusable modules. That's usually creating templates and fields and maybe also permissions. For all those things you can use simple methods like $rm->addFieldToTemplate("fieldname", "templatename") that behind the scene do all those things that you need some deeper understanding of PW's inner workings (like handling fields in fieldgroups). The RockMigrations API is built in a way and wording that sticks to the way you work in the GUI. createField(), createTemplate(), addFieldToTemplate() etc. The latter one for example does this, which shows how you can use fieldgroups from the PW API: https://github.com/baumrock/RockMigrations/blob/4de5edf7d037935af756243f8b055e91a142563f/RockMigrations.module.php#L395-L424
  17. bernhard
    A template has an assigned fieldgroup and a fieldgroup holds all the fields. In the PW GUI it looks like you are attaching fields to the template, but you are actually attaching them to the fieldgroup. You could simply use RockMigrations for that tasks... The main reason why I made it public is so that others can use it to easily build modules with it using the far easier syntax compared to doing those things with the default API (as you have realised).
  18. bernhard
    Thx, that is very strange!! The text you are seeing are just PHP comments in an empty array. Maybe a bug in the file compiler... I have moved the comment above the array. Can you try version 1.10.5 please?
  19. bernhard
    Big thanks to @Pixrael for being my first github sponsor ? This is exciting and I really appreciate the appreciation ?
  20. bernhard
    Hey @MrSnoozles I've played around a little with the new alfred syntax. I've used WireMarkupRegions to modify the markup when an alfred attribute was found, which was great. But then I realised that this breaks the code icon with quicklinks to the latte file. Which is not great! I don't think that I can do anything about that, so I think it's best to stick with the function based solution (either via latte or via php). Though I've just pushed an update that adds a short syntax for this: <div {alfred($page, ['fields' => 'title,images'])|noescape}> to also support that: <div {alfred($page, 'title, images')|noescape}> The old syntax is still supported for backwards compatibility and to support providing fields as array instead of a string. RockFrontend will even check if the field exists, so that editing will not break when requesting non-existing fields like "title, images, doesnotexist"
  21. bernhard
    Hey @MarkE that are good points, thank you very much ? Ideally I'd like to have a video to showcase the module and give a quick idea what it does and how it looks and feels like. And for the details I'd have the readme or in-depth-videos. That would mean the videos would get shorter (max 10minutes) and we'd also get a good overview in the readme. What I'm at the moment struggling a lot is to keep my readmes readable. I'm always having lot's of things to say but I feel it's very hard to find a good way to structure its content ? Any tips are welcome! Next try will be RockMigrations I guess ? Or maybe a video about hooks. Or one about module development... Let's see ? Yeah that fits into what I said above ? Thx ? I've done some videos over the last 20 years, so I was not totally blank - but almost ? There are also lots of helpful videos about everything you need and I find that a great way to learn. That's one of the biggest motivations for me doing videos about ProcessWire ? The video has been edited using Davinci Resolve - unbelievable that this software is free!
  22. bernhard
    Your IDE should also have an outline view that is built for this purpose: Does that help? Or are you meaning something Else? ?
  23. bernhard
    Sorry, I don't understand... There's plenty minutes of video for the render() method and I'm also showing renderIf() and renderLayout(). And I show how to use typehints to get docs directly into your IDE. What is missing? Again: Typehints ? It's easy to document all methods as good as I can in code, but it's impossible to write docs for every single method and even more impossible to add a video for every method... But RockMigrations is definitely a good candidate for a next video ?
  24. bernhard
    Hey @MrSnoozles thx for the input!! ? Puh... I'm not sure ? I agree with you that it's nice to understand code without having to look anything up. On the other hand I'm not sure what would be a better naming? In code and in the docs it is a huge benefit to just refer to it as ALFRED because it's short and crystal clear what is meant. In code for someone not knowing alfred that's surely not the case, but it would be just as simple to look it up and quickly find and understand what it is doing. Don't you think? I could easily add an alias though. But I'm not sure if that is a good idea because it could cause name collisions with the core frontend editing?! What would be a good name in your opinion? What do others think about that? I was looking for that statement as I think it was really a good hint! Thought I have been dreaming ? I have played around with my code a little and think that that we could really simplify alfred syntax even further! // edit current page <div alfred> // edit given page+fields (latte) <div alfred="{$page}:title,gallery"> // php <div alfred="<?= $page ?>:title,gallery"> That could work using the page::render hook for replacing the tags, so one wouldn't even have to think of using the |noescape filter any more!! Thx! I have removed that part from the video as it already got so long... See this post that is using the old (alternative) syntax: https://processwire.com/talk/topic/27187-domid-labs-– microsite-for-a-museum-related-project/?do=findComment&comment=224750 This approach has major drawbacks IMHO: You need to add the scripts and styles tag manually to your markup, which is not what I call "zero-setup". I've had it working like this before I did the video, but then I realised that there's actually some steps to do to get everything working as it should. So I came up with the hook-based approach. And I really like that approach even if that means that it hides some parts away, which is a valid point... When injecting scripts or styles from your sections (or components, or modules) you need to make sure that those scripts are loaded BEFORE the scripts are rendered in the head. That's similar to the delayed output pattern of processwire. The markup would look like this: <?php // render layout first, so any of your sections can inject scripts or styles $body = $rockfrontend->renderLayout($page); ?> <html> <head> <?= $rockfrontend->styles()->add(...)->render() ?> <?= $rockfrontend->scripts()->add(...)->render() ?> </head> <body> <?= $body ?> </body> </html> The thing is that I really want ALFRED and livereloading work out of the box. Zero-Setup. If you want to use the alternate syntax you can do so. RockFrontend is smart enough to see that you are rendering scripts/styles manually and will not inject them twice ? What do you think?
  25. bernhard
    Thx everyone!! ? What do you mean? Ah, thx, that's a good idea! I'll try to think of that in the next video ? Yeah I have the same feeling. Yeah, I agree, thx for the input! ------------ What do you guys think of the forwarded sections with 200/300% speed? Is that a good solution?
×
×
  • Create New...