Jump to content

LostKobrakai

PW-Moderators
 View Profile  See their activity

  • Posts

    4,956

  • Joined

  • Last visited

  • Days Won

    100

 Content Type 

Everything posted by LostKobrakai

  1. LostKobrakai
    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; }
  2. LostKobrakai
    @wuvidda This is an english speaking forum. Please include at least an introductary paragraph in english language into your post.
  3. LostKobrakai
    <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.
  4. LostKobrakai
    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.
  5. LostKobrakai
    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. Edit: If you're using jQuery in your application logic, you can't help but know how you directly manipulate the DOM and need to account for all the details needed to change it. That means your application logic will always need to be update if you want to alter behaviour down to the updates to the DOM needed (e.g. change detection to keep changes minimal for performance reasons). That’s a recipe for disaster. You should absolutely be using a javascript view library to abstract away what parts of the DOM need to be updated. Libraries like Vue, React, Svelte, … abtract away the low level DOM manipulations behind facades, which allow you to focus on building your application in a rendering-agnostic way. This goes as far as using e.g. reactnative outside the browser. Arguments like that can be made for any layer of abstraction out there. It's a matter of which level of abstraction makes the most sense for a certain project to be written in.
  6. LostKobrakai
    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.
  7. LostKobrakai
    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.
  8. LostKobrakai
    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.
  9. LostKobrakai
    I think the confusion is mostly in terms of managing expectations. It works if you just want to move plain data without caring much how it's actually moved. If you on the other hand have a tightly integrated system, where ids of things should not easily be changed then you might not want to use it. The big issue is that there's not much documentation on how exactly things work (especially in terms of conflict resolution) and about the obstacles you might encounter in the process.
  10. LostKobrakai
    There‘s no fixed list of things creating variations. You might install a new module, which creates ones or you setup the admin theme to use images as avatars, which might use a different size to the image inputfield preview. An update to processwire might change the dimensions of variantions used (even though Ryan is quite careful with those changes).
  11. LostKobrakai
    Personally I really favor it though. It might be more manual work to update, but also less prone to break stuff.
  12. LostKobrakai
    I'm wondering why you need to identify the default variation in the first place? Only use the sizes you generated and you should be fine and it won't break whenever any other functionality generates other sizes. It's not just the default variation created for the image inputfield, which might generate extra variations.
  13. LostKobrakai
    I'm not really in favor of "inheritance" for this kind of usecase. I like code generation much more if something shall be editable. Like put all you basic, low-level components in some class or helper functions and have some means (cli or otherwise) to generate higher level composed template files in the users project. This way you're doing a bunch things: Show/teach users how to compose your low-level components. Give them the ability to modify with hardly any restrictions. The "your update broke my changes" problem is much less of an issue and easier to control. It's just the low-level components which need to be backwards compatible and not a maze of hooks and overrides and stuff. Generators can be split up and used more focuses and all throughout a projects lifetime. It's not going to get harder the older the project gets. Generators can change without code of users breaking. They might just complain that the old results are no longer available to be generated.
  14. LostKobrakai
    That depends on how the regulations are actually translated into law in the european countries (each need to do that on their own). But I'd say as soon as the sharing part of the uploaded data is a primary goal you're very likely to need to do so. I still hope things like plain user images won't be inclueded. Iirc some of the politicians said in an interview that e.g. tinder would not be affected, which keeps that hope up a little bit ?
  15. LostKobrakai
    Flags are only for internal use. You most likely cannot use them in selectors. Also you don't need to try to be efficient when selecting templates, as all templates are loaded as part of the processwire bootstrapping process, so you can simply iterate $templates and select only non system templates without using a selector. Everything's in memory anyways.
  16. LostKobrakai
    You can't. The inputfield does generate one non-cropped preview image with the shorter side being double the gridSize setting. I'm not sure if the adminThumbOption is even used anymore after the new images inputfield replaced the old one.
  17. LostKobrakai
    GridSize was introduced by my work on the image input field. It's the size of the square images in the grid view of the inputfield. Afaik it is duplicated to cater for hidpi monitors by default.
  18. LostKobrakai
    If you're not harnessing the backend from ProcessWire I'd personally tend to not use ProcessWire. While it's entirely possible to do so (maybe also search for prev. discussions on the topic) there are some parts, which in my opinion discourage that kind of usage: Lack of proper testing capabilities. There are topics on how to do TDD with processwire, but the options on managing db state or handling requests in tests are not there. If you need to manage a lot of diverse data the autoloading of every template/field on each request can become a bottleneck. Working around it by reusing more fields/templates can work, but isn't great either. The selector engine for pages is great for light to medium complex stuff, but complex selections and especially aggregations need custom SQL or third party solutions like RockFinder. Also if you're not careful it's tempting to fall into n+1 query problems with fields / relationships being lazy loaded by default. Transactions are hardly used by the core, so if you want/need to prevent partial updates from happening you need to ensure that on your own by wrapping stuff into transactions. Not to say ProcessWire isn't otherwise a nice system, but those are the things I'd urge anyone to evaluate before using ProcessWire in a web application project.
  19. LostKobrakai
    You cannot use the same field multiple times in one page. What you'd need to do is use a field, which allows you to add multiple "sub-pages" like repeater / page table / pro field matrix. You could also simply use the pages children if you want. There are a few other multi value fields in processwire, but those don't seem to fit what you're describing.
  20. LostKobrakai
    @bbeer It's not. FormBuilder does not use Fieldtypes, but only Inputfields. This module is just a custom Fieldtype using the core InputfieldSelect for it's input.
  21. LostKobrakai
    The domain could be saved separately and probably not even be considered PII. What would be lost by using encryption is any kind of db powered fuzzy search for email addresses.
  22. LostKobrakai
    @flydev For http basic auth I'd only use user/password for initial logins and for any subsequent request use some kind of token. Generally I'd support what you said about tls and intercepted requests holding any information be it a password or token, but I think more important is the fact that a user won't insert a password for each request and you don't want your app to somehow cache the supplied password. That's what should never be promoted.
  23. LostKobrakai
    $page->prevAll("sort=sort"); This should force the order.
  24. LostKobrakai
    Sure has, but it's what you do with most everything else in processwire as well. Are the read/write patterns really that demanding that it would matter? But if only one field of yours is multi-language I feel like it should be quite possible to adapt existing patterns from other fieldtypes.
  25. LostKobrakai
    It's strange that even the field by itself returns null here. It should normally be at least something.
×
×
  • Create New...