LostKobrakai

PW-Moderators
  • Content Count

    4,667
  • Joined

  • Last visited

  • Days Won

    96

LostKobrakai last won the day on November 28

LostKobrakai had the most liked content!

Community Reputation

4,691 Excellent

3 Followers

About LostKobrakai

  • Rank
    Hero Member
  • Birthday 11/29/1991

Contact Methods

  • Website URL
    http://www.kobrakai.de

Profile Information

  • Gender
    Male
  • Location
    Munich, Germany

Recent Profile Visitors

15,467 profile views
  1. For composer itself: interoperability and a far bigger ecosystem. For wrapping packages into pw modules: Please don't wrap packages for the sake of wrapping them. It's useful if you provide additional features like configuration through the modules or deeper integration in processwire classes, but that's work and needs to be maintained on top of the package by itself. The only backdraw a plain composer package has on top of a pw module without additional features, is that it can't be installed via the backend, but you need to use the composer cli (and that's more a restriction of composer than of pw). The same is actually also true for the few pw modules which install composer packages. Another problem of wrapping packages is that you cannot get updates without the wrapping module being updated. There is also lot's of tooling like checking for security issues around composer. For anyone not just doing php as a hobby I don't see a reason not to use composer just like nobody uses javascript without npm anymore for any serious work.
  2. That's what I was refering to. Afaik /vendor is not blocked by default just because there are packages out there containing assets, which need to be web-accessable. I'd personally also lean to just block it.
  3. Just to clarify the bit about "putting stuff outside the webroot" for security reasons: This is certainly a nice precaution, but processwire is not using it because there are way to many shared hosters, where it's simply not possible to go outside the webroot. I'd also say that if your webserver is not behaving correctly you've got bigger problems to deal with, so usually just adjusting your .htaccess file should be perfectly fine as well. Especially as your php process still needs to be able to read things even if they're not within the webroot to be able to execute them. There's not really a need for composer for that part as processwire has it's own psr-4 compatible classloader: https://processwire.com/api/ref/class-loader/
  4. LostKobrakai

    This seems to be an index page. Are you sure the error happens on the first item of the collection? In other words did you check all items for that key as you‘ve only posted one here.
  5. LostKobrakai

    There are three things to consider for load balancing: You need a central database, central file management (if people do upload things) and central session management (as the default also uses the filesystem). Each can be solved in various ways and depends mostly on your project's constraints. Database Probably as simple as running the db on it's own external server. File Management - Cloud storage (S3 or equivalent; minio for self hosted S3) - rsync (this is at best eventually consistent as you need to wait for the sync) - mount network share (I've not tried this and read a lot of bad things, but it might work) Session Management - Use the central db for session (SessionHandlerDB; might be slow) - Use a central redis server (can be done directly in php)
  6. LostKobrakai

    Hooks are the way to go for validating business requirements.
  7. LostKobrakai

    Because it's (loosely) based on the selectors engine you select pages by and because it was never intended to serve bigger validation purposes, but more of a convenience tool to quickly show/hide things based on some external data. Having that it was a quick thing to add "required if" as another option besides "show if". So all in all: historical reasons. Real validation needs to run on the server side, and while show if and required if is checked against on the server side the main functionality it added at the time is the client side in showing/hiding fields and or showing/hiding the required asterisk. So mixing both is in my opinion a ill fit without changes to implementation.
  8. LostKobrakai

    Afaik ryan's position on hard constraints in form validation is that they don't work and you should expect things to be off. Like what happens if you change a input field from min. 1 to min. 2 images. Suddenly all your pages are in an invalid state and there's no form validation, which can save you from that.
  9. LostKobrakai

    Yeah, there are ways to use webp as progressive enhancement, so there's no need to detect browser support on the server side.
  10. LostKobrakai

    You can look into the FieldMigration class to see what it does on migration/rollback. It should just remove the field itself. If that doesn‘t clean up the fieldgroup than it‘s expected behaviour. You can still override/add to that by putting your own upgrade/downgrade functions like e.g. I did it here: https://github.com/LostKobrakai/MigrationSnippets/blob/master/Reverse_Template_Migration_Type.php
  11. LostKobrakai

    Laravel or Symfony are first and foremost general purpose frameworks, while ProcessWire is first and foremost a CMS with the benefit of having a small general purpose framework beneath. The difference lies mostly in what you get out of the box and less so in what you can build with it. E.g. laravel/symfony have components for using queues, processwire doesn't, laravel/symfony have a templating system, ProcessWire doesn't (it's php), …. On the other hand ProcessWire comes with a flexible backend to hook into, laravel/symfony don't have that (laravel nova would be similar, but costs money).
  12. LostKobrakai

    The problem I have with static json or yaml setup files is that it's not migration. It's just a static set of fields/templates/… without knowledge of what came before or after. I have almost always user generated data associated to a certain setup. So when changing the setup there's often the need for something to happen with said data as well, like when adding a new intro field for blog posts one might want to put the first paragraph of existing posts from the body into the intro. Craft seems to see their addition just as replacement of sharing db dumps and it's essentially that. If environments never concurrently change in terms of content, but just structure then some version controlled file for the structure is better than a db dump, which contains both structure and content. But as soon as the content is also affected by changes it's no longer a solution.
  13. LostKobrakai

    @bernhard I've not much time to work on my OSS stuff at the moment, as I'm no longer actively using it in my everyday work. But I'd happy to collaborate if someone wants to make a companion module and make sure the needed functionality is callable on the module.
  14. LostKobrakai

    The problem is that a middleground is even more complex. Either your prod environment doesn't change (in terms of what's in the db) then you can simply use db dumps, or your production environement's db does change concurrently to the dev db. The same is the case if you're working in a team of people as well. If the latter does happen you need some way to know what to update and what not to touch. Migrations is doing that by letting you manually define migrations, which are the stuff, which needs to be changed. This gives you full control and you can basically update anything in processwire by using the api. You can also still do stuff on your dev environment, which is not somehow automatically applied as change to prod. Bonus point: replayablility / reusability. What you're looking for is some way to basically let the computer do what you've to do manually with my module: detect what's to change. This could work for simple changes like in fields or templates, but does easily get quite complex is the not so simple cases, e.g. repeater matrix. For pages it's already getting not that simple. You might create pages, which are just for your dev work or pages, which need to be created in prod as well. One could manage whitelists or blacklists (of branches), but that's also a thing to maintain. Also if such a module is not super flexible you'll be bound to execute what it thinks did change. Most often such algorythms don't like a human to adjust their results, especially if steps depend on each other.
  15. LostKobrakai

    After a while it became even easier for me to just copy&paste together new fields/templates instead of creating them in the UI. There's certainly a transition phase, though. The UI I use mostly for when I'm not sure how to build something yet. For any project with a somewhat longer period of active development/maintainence I'd really suggest anyone trying it.