LostKobrakai

https://modules.processwire.com/modules/process-page-list-multiple-sorting/

Yeah most frameworks nowadays automatically parse json data into post data.

This seems to be a quite good lib: https://nosir.github.io/cleave.js/

Here's the bit more elaborate answer: https://processwire.com/talk/topic/16096-inputfield-ajax/?do=findComment&comment=143205

ProcessWire simply does not handle data submitted as json in the request body. It does only handle the php native formats, which are what <form/> can submit.

Maybe processwire could harness tus for chunked uploads. Integrating the existing js/php components into processwire might be simpler than writing a custom backend for resumable.js.

$pages->find($selector, ['load_options' => ['joinFields' => ['title']]]); This should allow you to join fields on demand.

Sure but harnessing autoloading + findMany might get you a long way without dropping down into raw sql. ProcessWire's db schema is not the most straight forward to write manual sql for anyways as it's quite join heavy.

Without trying to invalidate the endresult – mysql + joins will probably be faster – your example code is comparing apples to oranges. A $page->findMany does do quite a few things more than just a db query for data even if it's just constructing the Page objects and putting stuff in different caches. Also I'm not sure your title field is set to autojoin? If not that means you're comparing a single DB query to 4068 DB queries (1 for the items and one for each title). In cases where you're iterating a lot of pages you'll need to keep a look at the query count and not fall into n+1 problems.

There are also a lot of ways to leak data without having a full server compromise like publicly available sql dumps (put somewhere in the webroot) or permission issues on shared hostings. So encryption does still have a value even if the secret key and the encrypted content are on the same machine.

The GDPR was approved two years ago, so how much more grace period should there be? As with each new law it's not going to come with any set of "best practices". They'll be worked out as the first lawsuits are held and concrete situations will be applied to the rules. There just isn't anyone out there to really finally interpret written law into concrete ways of handling thing besides judges in a lawsuit. It's a bummer that the ePrivacy rulings, which are supposed to go more into detail in the enforcement of gdpr in the digital world are still in the sad state of being nowhere near final. There are also various sources reporting that the ePrivacy laws won't be able to come into action until mid 2019 based on what is still to be approved by the EU and it's member countries. That might be the case in places, but as the GDPR is enforced for each company working with data of european citizens it's going to hit almost any globally active company as well as european ones. E.g. AWS is already claiming that they're gdpr compliant. For heroku I didn't find conclusive info, but salesforce (which owns heroku) does have extensive information on gdpr and how to comply when using their service. So if US companies want to make money in europe they'll have to deal with compliance.

That's not true at all. A sql dump is just text (or a compressed version of that). Open it, remove the problematic lines and save it. You could also import it into a locally running database instance, make your edits and export it again. If you cannot make the necessary edits on your own you have to rely on the provider to do that for you. If the provider cannot / will not do edits to backups search for one that can do that. The only backups I can see being potentially problematic would be the ones, which save only diffs to the last backup and not a full copy. But I doubt there being no way to built tools around those systems to be able to edit parts of a backup without breaking the integrity of all following backups. It's certainly not. Take the AshleyMadison leak for example. How would you feel if you made a request to such a website to have your account being fully erased just to show up in a leak some time later as a result of a database backup? It's not even about the backup being used for a rollback, it could also be the backup which gets leaked.

I even co-own a company, so that's certainly on my plate as well. Also GDPR is not limited to data stored online. If you take a survey on paper you're not allowed to store it forever either. If your latter points are the case and they have the consent of the user to use personal data in the way they do, then they should be compliant (I'm not a lawyer). If data is used in a reasonable and consented way and is secured in a reasonable way why wouldn't that be compliant? For small businesses it's also way easier to keep an overview about where and how data is stored, which 3rd party providers are used and so on. It's also easier to call attention to those changes in law on a smaller set of employees than one operational in multiple countries. Sure it's not getting easier, but I don't feel it's a task not doable. I mean lots of those rules are already in place here in Germany and it seems to kinda work out. It's not like you mistreated one piece of personal data and you'll right away be fined to the maximum penalty. Without a data-breach it's even questionable who'll control those small companies for complience.

It does support my hunch that ProcessWire is quite big in Germany

These are surely issues, but it's the issue of the company not the enduser, whos data is stored. Me as a private person is actually glad that companies need to clean up their management of data, as it's really more about handling data carefully than being denied handling it. I'm sure it won't be perfect (looking at those email inboxes), but companies might move to an more appropriate tool for the job (e.g. a customer helpdesk), where data is globally stored for the company. Nobodys email inbox will receive any personal information handled in the helpdesk and it's easier to know where a persons data is stored, to comply to "forget requests" and such things. For me I also feel like the gdpr is far more important in the space of "managing data handling" and "knowing where data is stored/processes" then the addition of "getting consent". I mean people are already having to give consent for almost everything – maybe a bit more in the EU then in the US – just that now those "terms and conditions" need to be readable to normal human beings instead of just lawyers.

I doubt it makes any difference if data is stored in an email inbox or on some webserver's database. The regulations apply to any data you store or process (storing and processing are clearly separated roles) if that's digital or analog or on post-its. To the contrary I'd even prefer the database in cases of form submits, because an email is easily forwarded to different people in a company and complying to a "request to be forgotten" can result in hunting down all the inboxes where submitted personal data are stored, while deleting a record in a db can be a lot easier.

This is probably because cookie handling is supposed to be regulared by the eprivacy law, which will be obliged at the same time as the gdpr, but is a separate regulation. Sadly this one still doesn't seem to be finalized and it's getting far less attention.

My migrations module cannot install processwire, nor itself, but after that it can basically do whatever php and the processwire api allows you to do.

I don't think specifically learning jquery is needed anymore. I'd rather try to improve your skills of using plain js, which should result in using jquery being more or less "reading the docs" if you need it. If the foundation in plain javascript is given or you start to have spaghetti code then look into the OOP features of js and frameworks like Vue/React/Angular. Additionally I'd like to add Svelte to the mix as well. It does look quite similar to Vue, but does include less of the features/magic one might not need in Vue. It's api look way more like plain javascript.

Webpack is actually the bundler, which does support code splitting the best out of the things I tried. It's also quite manageable by using the laravel-mix wrapper, which contrary to it's naming is not in any way usable only with laravel. It takes all the daily-business use-cases and makes them easy, while you still can plug things into the underlying webpack directly if needed. I'm currenly working most of my time with the phoenix framework, which does include brunch as default frontend build tool. Some people try to get things to work with it, some switch to another bundler right away, but besides for really simple needs it's just not developed enough. The best issue I know of is, that it's including things in the order they're listed in the packgage.json in some places, but npm nowadays actually orders dependencies in alphabetical order in that file. So if order does matter you need to actively revert that behaviour of npm.

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.

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.

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.

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.

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.