• Content count

  • Joined

  • Last visited

  • Days Won


LostKobrakai last won the day on June 20

LostKobrakai had the most liked content!

Community Reputation

4,353 Excellent


About LostKobrakai

  • Rank
    Excited Member
  • Birthday 11/29/1991

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Augsburg, Germany

Recent Profile Visitors

13,778 profile views
  1. I'd try to keep things decoupled. So if your php functionality does not depend on anything processwire I'd keep in in a separate class/file even if it's going to be used in a module, which does bind/hook the functionality into processwire.
  2. PW ultimately calls $user->hasPermission() with the supplied permission info, which does expect a single permission to be used. So you'd use the permissionMethod for multiple ones.
  3. It’s certainly a different language, but besides any language/runtime based differences it’s actually not to different to use phoenix compared to using e.g. laravel in php. It’s got routers, controllers, views and behind that some business logic. I also noticed that the functional nature of the language does actually make the latter easier to understand than some oop classes and I found learning a functional (/actor based) language actually made me understand some principles behind oop quite a bit better. Anything which you’d use laravel or similar frameworks for in the php world or rails in ruby. So custom web-applications, json api's, applications which often require things to run longer than the few second web requests. So kinda anything which is not just a website (cms) with a handful of forms and not full on e-commerce. I'd also do websites in elixir if they're supposed to handle a really big number of users / spikes of users. Some early adopters of elixir could reduce their number of servers to a quarter after switching to elixir (most from ruby/rails). For the thing's I'll be using elixir for the client's won't really care. We're not doing very many marketing sites, where the client might want to edit texts or something. We run a SaaS product, where any client interaction is on the frontend anyways and also some web-applications, which we fully manage for our customers. Those also have the most interaction with people using the application on it's frontend and very few to no interaction with the client themselves.
  4. I'm currently in a full on switch away from php to elixir, but I'd still not say php is generally bad. For websites with none or some business logic involved it's certainly good enough and has lot's of tools/people for moving quickly in that space. But I'd no longer use it for anything more complex or custom made. The things, which drew me to switch over where actually not the language per se, but rather the environment: Elixir is a compiled language, which is way more performant than php. It's damn easy to do concurrent computation harnessing the power of multi-core cpus, which is just a pain in php (react-php or threading). Long running computations are hard to do in a php world, where 98% of the time each request starts/terminates the whole world. Sure one can start a php script in the cli, but it's the communication which is the annoying part. Websockets or http2 streaming are the things in the web world, which are only possible with long running processes. Elixir does come with a own testing framework within the language. Code documentation is first-class citizen and the community/package manager push people actively to use it e.g. with automatic documentation hosting for packages. So there's a kinda canonical place for documentation and hell can it be good for the more popular packages. In PHP there's not even real consensus about using composer. And the final point is that a functional language with immutable data does now fit my mind way better than oop and shared memory.
  5. I would try to hook the code, where the label is generated and not bloat all the pages with additional fields just to show a string in the pagetree.
  6. I don't think we can use grid for global layout soon. But for single components it can be just as useful in places and it doesn't seem like to much of a hassle to have less sophisticated looking fallbacks for those smaller usecases.
  7. @abdus Handling modules is realm of the superuser as one can potentially break lots of things there. If you need non-superusers to edit module settings I'd create a custom process module, which does handle changing the module config in a more secure way with validation of changes and alike.
  8. The superuser is like it's names suggests super. It's like the admin user you get in each other system out there. There aren't any access restrictions on that role. It's meant for the people developing the website and should not be used for content-creators. Also it wouldn't make much sense to add access restrictions to an user, which most likely has access to any configuration files as well as the database behind the website.
  9. I've just merged the changes of @Macrura.
  10. Here's a primer on what hooks are and how to use them: https://processwire.com/api/hooks/. They're essentially a way to add custom functionality within processwire's workflows.
  11. Just a word of caution. Do not use this in high traffic pages, because it holds a race condition, where people might be assigned the same number.
  12. You could build some custom logic into templates/admin.php to switch the language to something else temporarily. But by default switching languages for users does use one and the same field to store that switch. So you'd probably need to add another field to the user to store something like a "backend_language".
  13. When we're already at chromium based browsers: Opera is also based on it (actually for quite a while by now) and it's been the first time I stayed with it longer than 2 or 3 weeks.
  14. There's $template->altFilename which I think is relative to the templates folder.
  15. @ryan I'm curious did you read my ramblings in the wishlist topic (and elsewhere when the topic poped up)?