Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


LostKobrakai last won the day on February 19

LostKobrakai had the most liked content!

Community Reputation

4,864 Excellent


About LostKobrakai

  • Rank
    Hero Member
  • Birthday 11/29/1991

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Munich, Germany

Recent Profile Visitors

16,350 profile views
  1. You could try using a PHP hannacode with: ?> <html>test</html> <?php
  2. Gitea is great. I had gogs (which gitea forked) running on a server of mine for a while, but gitea is more active and open. But I must also say I only use it locally to move repos from my laptop to the desktop for all the WIP stuff, which doesn't need to be in some cloud already.
  3. I really like the side by side layout for content and nav. I imagine it being a great solution to cut unnecessary cost in catering to smaller screens and larger screens with different layouts.
  4. My question was less about the field definitions, but more about the data stored in a field defined by your module. E.g. say I want to change an integer field to a float field.
  5. Can you share a bit more details on how data is handled. E.g. what happens if I change a field or even remove it.
  6. For me it was a platform switch away from ProcessWire and even PHP. It had nothing to do with DynamicRoles at all. Without the issues mentioned/open prs on GitHub it should work fine. I've even looked into making it even more flexible once, but never finished the work.
  7. I'm also no longer using DynamicRoles in a production env. It was working well though with the fixes I proposed in the repo and on pw 2.7.3. An addition to @szabesz comments above: The thing to keep in mind with $page->viewable() as the "Solution for Access-Control" is that it's easy for it to not be enough. As soon as pagination is needed one needs access control at the database layer or pages will have different numbers of elements (even down to none at all).
  8. So without the croppable image module variations are generated on demand. If your clients upload quite big images and you want to generate a maybe even larger than needed set of variations this is going to take some time and even more memory on the initial request. But that's a whole different problem than "how can I not create the default variation for an image" with completely different ways to get to a solution. I still don't get why you insist on filtering down all available variations wherever they might come from. I expect you have a list of sizes for your srcset defined somewhere, so just use those. You can still check the images dimensions to filter out the sizes you defined greater than the image's dimensions. Something like the following. <?php function responsive_image($image, $widths = null) { $widths = $widths || [200, 400, 800, 1200, 1600, 2000]; $default = 400; $smaller_widths = array_filter($widths, function ($width) use ($image) { return $width <= $image->width; }); $srcset = array_map(function($width) use ($image) { return "{$image->width($width)->url} {$width}w"; }, $smaller_widths); $srcset = implode(", ", $srcset); return <<<HTML <img src="{$image->width($default)->url}" alt="{$image->description}" sizes="(min-width: 640px) 60vw, 100vw" srcset="{$srcset}"> HTML; }
  9. @wuvidda This is an english speaking forum. Please include at least an introductary paragraph in english language into your post.
  10. <picture> <img src="<?= $image->width(400)->url ?>" alt="<?= $image->description ?>" sizes="(min-width: 640px) 60vw, 100vw" srcset="<?= $image->width(200)->url ?> 200w, <?= $image->width(400)->url ?> 400w, <?= $image->width(800)->url ?> 800w, <?= $image->width(1200)->url ?> 1200w, <?= $image->width(1600)->url ?> 1600w, <?= $image->width(2000)->url ?> 2000w"> </picture> What's wrong with doing it like that? You won't need to care about the naming of any files at all. You can also automate that even more to have customizable sizes for the images. For the webp topic I have to say I'm not up to speed on horsts work, so I'm not sure how to handle that.
  11. As I've mentioned svelte already and the filesize argument was used: https://v3.svelte.technology/repl?version=3.0.0-beta.22&example=onmount This example downloaded and compiled results in a 4kb javascript bundle. I'm quite sure even just the code using jquery would need about half of that size to do the same excluding jquery itself. So there are more modern ways to have the benefits of a nice view library in javascript without the need for bloated runtime library code. Svelte has a tiny runtime library, which can even be tree shaken (only include what's needed), while the heavy lifting is done at once at compile time. The better part of your file size bundle will only consist of the actual stuff you build using it. It's only sad that it's currently in a "please don't start using v2 anymore, but also wait till v3 is done" phase.
  12. I'm really wondering when this book was written though. I've not had major problems with differences in browser implementations in years. The bigger problem is support of APIs, which might not be present in all browsers, but those are imho better solved by adding polyfills, which can be removed once browser support numbers are high enough without changes needed to be made to the actual javascript. I mean jQuery is still a valid choice today if you need it. I just feel the number of times you really need it is diminishing. Browser APIs getting better is one reason for that and the move away from imperative DOM manipulation to more abstracted view libraries is another. jQuery's move to slimming down it's core size might also have been just a notch to late, when everybody was already migrating of of jQuery.
  13. I still don't really get what your problem really is though. Like what exactly is not working for you in the current system? Normally you just instruct processwire via the api calls which variants you want to have and processwire takes care for you that those are available.
  14. My migrations module has generators. Basically everything creating a migration file for you is one. Just that those are meant to be edited further, while files generated by modules would work as is. Generally I think you‘re quite fine as you‘re doing modules and the sites using them by yourself. It‘s getting more complicated if things are no longer in one hand and happen independently from each other.
  15. Quite correct Migrations are supposed to be immutable files, so running them always yields the same effects. This is best accomplished if those migrations are managed in one central place by the entity affected. Nothing outside should implicitly be able to affect what migrations do. Having migrations in modules however does exactly that. If you update a module the migrations in it might be updated, which is not good (it might have already been executed in prod with the old code and later migrations depending on the new code might fail). Even having immutable migrations in the module might quickly become a burden as each new user must be moved through all „mistakes“ and „changes“ as well before being migrated to a final state needed by the most current version. While I‘ve talked a bit about the mentioned downsides I also think modules should come with migrations, but in a different form. There should be generators, which generate migrations in the central migrations folder of the site using the module. They imho should always just generate the most recent version of migration needed. If a module does change the way to update old clients should be by having migrations to update from e.g. V1->V2. Those could be put in another generator or even just be put into a changelog. New users of a module wouldn‘t need to care about it, they directly get migrations generated for V2, existing users can leave their existing migration for V1 in their system and just add the update migration for V1->V2. This way one can have the benefits of modules supplying migrations to users, while not having the downsides and a imo simpler option for not needing to keep track of all the old stuff already changed till eternity, especially for new users, which really don‘t need to care about old versions. One last benefit of generation of code is that it‘s editable by the user. Like I could add localized labels to a field generated for a certain module, without any extra effort needed by the module creator. Another example might be adding additional fields to a template a module uses/creates, which might be needed just on the single site. This is also a downside, as editing could break the functionality, but I think it’s a quite clear danger and one can always generate the file(s) again to get to a working migration. Edit: One last point. Migrations in modules like they're intended by @bernhard can work as well. I hope it's clear that most issues I pointed out above are about control, the one for the actual system using the migrations. I'm not keen on automatic stuff happening, which could break my system. Others might be happy to let module creators be in charge of not skrewing things up. On the other hand control means more responsibility, like changes in versions are a little bit more work for the module user.
  • Create New...