Jump to content

bernhard

Members
 View Profile  See their activity

  • Posts

    6,674

  • Joined

  • Last visited

  • Days Won

    367

 Content Type 

Everything posted by bernhard

  1. bernhard
    You could try to delete the row of your module in the "modules" database table. That would mean that the module is uninstalled. Then you could check if the module get's installed automatically on the next page load or modules refresh. If it get's installed you could add something like this to your install() method of the module: bd(debug_backtrace()); die(); In that backtrace you should then see what is triggering the installation of the module.
  2. bernhard
    I can't reproduce this behaviour. Both return the page properly.
  3. bernhard
    Just install the module on another ProcessWire installation. If it's the same behaviour there the issue is in your module. If it's different, then the issue is in your current project. ?
  4. bernhard
    Uneducated guess: I think it should be fine.
  5. bernhard
    Sounds exactly like what the admin search does? ?
  6. bernhard
    @gebeer I'd love to have better docs, but I don't like github wikis - that's why I built my own docs system on baumrock.com It reads module docs from markdown files that are stored under the /docs folder within the module. See https://github.com/baumrock/RockFrontend/tree/main/docs for example. Would be great if you could create a PR for RockMigrations that show that info on my website like here: https://www.baumrock.com/en/processwire/modules/rockmigrations/docs/deployments/ I'm busy with client work for the next weeks, so any help is very welcome ?
  7. bernhard
    Have you seen RockLanguage? There was no feedback at all...
  8. bernhard
    Hey Jens this works great, thank you! {* page background image *} <picture id="page-bg"> <source media="(min-width: 1400px)" srcset="{$home->backgroundImageUrl(1920)}"> <img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAAXNSR0IArs4c6QAAAAtJREFUGFdjYAACAAAFAAGq1chRAAAAAElFTkSuQmCC" alt="Page Background"> </picture> And the css: body, html { height: 100%; width: 100%; } #page-bg img { position: fixed; left: 0; top: 0; width: 100%; height: 100%; object-fit: cover; z-index: -1; } I'm using a transparent pixel data-url by default (taken from https://shoonia.github.io/1x1/#00000000).
  9. bernhard
    I'm not 100% happy with that wording. No offense, just want to be clear on that. It's not that I don't want to support RepeaterMatrix to push sales of RockPageBuilder. I'm just not using RepeaterMatrix any more because RockPageBuilder is far better for what I use it and it integrates well with RockMigrations. RockMigrations is a module containing thousands of hours of work that you get for free and that does not pay any bills for me. I just can't put any (more) unpaid work into it unless I need the features for my own work. But I'm happy to support RepeaterMatrix and any other pro field of Ryan if people provide PRs even though that might mean less sales for RockPageBuilder. I'd be even more happy if @MarkE had a look at RockMigrations and used it as common base so that we can work together on an api that does all the heavy lifting - independent from wether it is used by RockMigrations or MarkE's GUI. And even more happy, of course, if we had a migrations API in the core...
  10. bernhard
    I'm working on a website where I want to add an image as background: The image comes from a PW images field. So I can't add the image via CSS... I'm doing it like this: <html lang="de" class="uk-background-muted" style="background-image: url(<?= $site->bgImgUrl() ?>)"> In CSS I have this: html { height: 100vh; background: no-repeat center center fixed; -webkit-background-size: cover; -moz-background-size: cover; -o-background-size: cover; background-size: cover; } So far, so good. But I don't need that image on mobile, as it will never be visible. I only need it for screen sizes > 1440px. Any ideas how I could do that? I tried adding a <style> tag with @media(min-width: 1440px) { ... } </style> but that did not work. As soon as I placed it as "style" attribute of the html tag it worked. Thx for your help ?
  11. bernhard
    I've never tried it myself, but you should never change anything inside the /wire folder. Use /site/config.php instead
  12. bernhard
    Why do you want to do that? You can configure that via $config->pageNumUrlPrefix, but what you are trying to do is not possible by default (and maybe not a good idea at all). By adding the slash you basically let it look like another layer of the pagetree (or of your sitemap), but that's not the case, so I'd say it's logically incorrect. Also see here:
  13. bernhard
    Hey @Robin S thx for the helpful module. Used it today for the first time and unfortunately the "open in new tab" checkbox has no effect. I didn't find any occurences of "target" or "_blank" in the module's code, so I think it's missing ?
  14. bernhard
    Could you please explain or show how they do that?
  15. bernhard
    Hi @Rasso and also welcome to the forum. I'm always happy to answer questions and I always welcome constructive feedback. I just don't like if people post wrong information about my modules or put them in a wrong context. Before I explain some things, please have a look at the intro video that I did one year ago. Some parts are outdated, for example the module will not automatically copy snippets to your project, it will ask you before doing so. But all the main concepts do still apply and will likely not change for a long time. Actually @gebeer the video also shows how to move migrate() code into the pageclass. Totally forgot that ? That's not how RockMigrations works. At least not at the moment. And that has several good reasons. I'm not saying that such an approach is bad. But it is very complicated to implement, it comes with a lot of (maybe unsolvable) problems and even if everything worked it has a lot of limitations by design. I didn't want that for RockMigrations, so I built it differently. I can understand that it looks overwhelming to write migrations by hand. That's why RockMigrations does a few things more than only migrations. For example adding snippets (if you want and if you are using VSCode), so that you don't have to remember migration code by heart: If anything is missing in those snippets you can just create that field manually and then inspect the field's migration code: Or alternatively you will get the key-value pair by just hovering over the setting in 90% of the cases - for example changing the visibility state of the field to "open + locked (not editable)" you'd have to add "collapsed" => 6 to your migration code. This might be a bit slower than using the gui. And it needs a little time to learn the basics. But once you get the concept it's often a lot quicker than working with the gui. Especially if you have a more professional setup and take the whole picture into account (having a staging / production system for example or working in a team). But for a quick start: Just install the module and play around with /site/migrate.php The beauty of that manual approach is that you only write code that you really need. Having a gui that stores a snapshot likely means that you get a bloated json or yaml with a trillion of settings that you don't need and that you might never understand, because you didn't take the time to inspect the whole json. Manually writing migrations on the other hand means that you get beautiful diffs in your project's codebase: If you can read diffs you can instantly understand what that migration does, right? And if you have a look at line 71 you see that I'm using the Inputfield::collapsedHidden constant instead of the integer value 4 which you would get from a gui-based JSON/YAML migration file. I think that's much more readable and a lot easier to understand. And that's just another benefit of taking that extra step of writing migrations by hand instead of letting a tool do it for you. Another huge drawback of a gui based migrations tool with a central place of migrations is that you limit yourself to the project. Everything you do you do for the project. With RockMigrations you can split migrations into reusable components and place migrations where they logically belong. You might want to build a blog module that needs to create a "blog-overview" template and a "blog-post" template. Nice! Create those two pageclasses, add a migrate() method with all the template and field settings and voila, you have a module that you can reuse from project to project and only install it where you need it. Imagine you have built that blog for your project with GUI based migrations... You have another project request with a blog? Have fun, do everything again. Of course that comparison is exaggerated, but you get the point. RockMigrations is by far my most valuable module. It's stable, actively maintained for years and in daily use in many of my and many others' projects. I released it for free, because I think that this functionality should be built into the core and should be part of every more professional project. I thought we'd see more modules being released by the community, because RockMigrations makes it so simple to create modules that need fields/templates/etc. which is a pain to do with the API. I thought maybe Ryan might see what is possible and join the discussion. And I think it's a shame that ProcessWire is still said to be a good tool only for smaller projects. Unfortunately I was wrong in many points. But fortunately that does not matter too much. RockMigrations is stable enough so that I don't need a core solution any more. I'm very happy with how it works and how well it plays together with ProcessWire and it's fundamental concepts. RockMigrations offers exactly that. If you try it and have any questions or you have any suggestions for improvements from your experience with WP/Kirby let me know.
  16. bernhard
    Note that the module only stores the current count and not all the timestamps of each visit. That means you can get "trending topics" in terms of most views from the very beginning but not trending topics in terms of most viewed in the last 2 days for example. But you could certainly achieve something like this by hooking into the pageViewTracked event like I did with RockHitCounter: https://github.com/baumrock/RockHitCounter/blob/1bfe2531810d2e9e18177d9975fd4d868fda96a4/RockHitCounter.module.php#L34
  17. bernhard
    Thx. Fixed ?
  18. bernhard
    Hi @gebeer no, of course the page class' migrate() method can only be called once the template exists. But that is done automatically by RM if you use the createTemplate() method: That means all you need is to create your pageclass in /site/classes/FooPage.php and then in your Site.module.php (or wherever else) you do $rm->createTemplate('foo'); This is an example of my modules overview page on baumrock.com where I'm even too lazy to create the view file manually to make the page be publicly accessible, but you can do that manually if you prefer: <?php namespace ProcessWire; use RockMigrations\MagicPage; class ModulesPage extends Page { use MagicPage; const tpl = 'modules'; public function migrate() { $rm = $this->rockmigrations(); $rm->createViewFile($this); $rm->migrate([ 'fields' => [], 'templates' => [ $this->getTplName() => [ 'fields' => [ 'title', RockPageBuilder::field_blocks, ], 'childTemplates' => [ 'module', ], 'sortfield' => 'title', ], ], ]); } } This is my migrate() in Site.module.php: public function migrate() { /** @var RockMigrations $rm */ $rm = $this->wire->modules->get('RockMigrations'); // cleanup/reverts $this->cleanup($rm); $rm->installModule("RockPageBuilder"); $rm->setPagenameReplacements('de'); $rm->setModuleConfig('AdminThemeUikit', [ // use consistent inputfield clicks // see https://github.com/processwire/processwire/pull/169 'toggleBehavior' => 1, ]); $rm->setModuleConfig('ProcessPageList', [ 'useTrash' => true, // show trash in tree for non superusers ]); // install german language pack for the default language // this will install language support, download the ZIP and install it // $rm->setLanguageTranslations('DE'); // $rm->installModule("LanguageSupportFields"); // $rm->installModule("LanguageSupportPageNames"); // $rm->installModule("LanguageTabs"); // $rm->setFieldData("title", ['type' => 'textLanguage']); $rm->installModule("RockPdf"); $rm->installModule("RockMoney"); $rm->installModule("RockSearch"); $rm->installModule("RockMails"); $rm->installModule("RockForms"); $rm->installModule("RockCommerce"); ... // create global fields $rm->migrate([ 'fields' => [ self::field_search => [ 'type' => 'RockSearch', ], ], ]); $rm->createTemplate('pdf'); $rm->createTemplate('modules'); $rm->createTemplate('module'); $rm->createTemplate('release'); $rm->createTemplate('releases'); $rm->createPage( template: 'releases', parent: '/', title: 'Releases', status: ['hidden'], ); ... } Language specific migrations are commented out for performance reasons and only necessary once or maybe if new updates are available.
  19. bernhard
    Thx! Looks like I should update ? And great to hear that as this plays well with RockMigration's deployment ?
  20. bernhard
    The "correct output" you are showing is an absolute file path. On websites in the <img> tag you need an url relative to your site's root folder. That would typically be something like /site/templates/img/foo.jpg Not sure why your path shows "site-news" instead of just "site" though.
  21. bernhard
    A note for anybody using RockMigrations deployments: You have to add one line to your /site/deploy.php file: <?php namespace RockMigrations; require_once __DIR__ . "/modules/RockMigrations/classes/Deployment.php"; $deploy = new Deployment($argv); // add this line $deploy->share("/site/assets/div-queue"); // DelayedImageVariations $deploy->run(); Otherwise the queue-folder does not exist after the next deployment and the module throws errors, because the module creates this folder only on installation.
  22. bernhard
    @iank thx I've just pushed an update to RockFrontend DEV which will soon be merged into main. Can you please check if it works for you and mark this thread as [solved]? Thx ? And thx for your help in finding the issue!
  23. bernhard
    @Atlasfreeman if you find time it would be nice to mark this topic as [solved], thx ?
  24. bernhard
    @Klenkes if you find time it would be nice to mark this topic as [solved], thx ?
  25. bernhard
    I don't know of a PW way to do it, but you can quite easily query the DB directly: <?php // do proper sanitization when using direct SQL queries!! $sql = "SELECT pages_id FROM field_title WHERE data1034 LIKE '%plan%'"; $result = $database->query($sql); $pageid = $result->fetch(\PDO::FETCH_COLUMN); This returns 1170 for $pageid So if you modify the query to search for "Paket" in "data1034" this would return false. With a regular PW page selector it would still return 1170 as it also searches in the "data" column. Note that this query does not take any access control into account.
×
×
  • Create New...