LostKobrakai

I'd like to add that JWT is to be taken with a grain of salt. Once a token is issued there's not way to revoke it's validity unless one is storing something in the db to validate the jwt against. Having something stored on the server makes it essentially a more complex, more manual session handling, so there's at least in my opinion no longer a point to use JWTs. They're mostly useful for shortlived tokens or you can use them if you implement something like oauth or similar stuff. I personally wouldn't suggest using them like they're implemented currently in the module.

I'm not sure how much you intend to further work on it, but https://github.com/unicode-cldr might also be a nice source for information.

In the processwire backend you can already do the translation. There's not need for an external tool to add online translation.

ProcessWire's translation is based on gettext, so using po/mo as alternative to the json files we currently have should be quite possible. Afaik it should even be possible to convert between both formats. Those are certainly nice and I'm using PoEdit for other projects, but we should not forget that processwire ships with online translation handling in core. If you need collaborative web based translation you're already covered.

Ah yeah, I'm not doing much PHP anymore, so missed the difference. Short opening tags I'd not use as well.

Since php 5.4.0 short tags are always enabled, so that's not really a problem anymore, and really in template-files using them just removes a lot of unnecessary extra syntax. Just don't use them anywhere else.

There‘ll certainly be a shift in what tools like google analytics need to be able to do in terms of preserving user privacy (and they already do), but I don‘t see anyone wanting to seriously build page counters in php again. Matomo (piwik) already exists and there are even new alternatives like fathom, which are already enough for simple needs.

Valet does not use apache, so it‘s certainly no .htaccess issue. The routing is encoded in the drivers (hence the need for drivers in the first place). I‘m no longer actively using the driver, but it can certainly be that there are edge-cases, which won‘t properly resolve using it.

Reminds me of this one: https://gitlab.com/gitlab-org/gitlab-ce/issues/2105 (3 years by now)

30 pages * x fields is a whole lot of insert statements to do on every change to an order, but 20 secs sounds indeed like somethings off. That's nearly a second per page to clone. Is that the time it takes locally or in production though?

@Jonathan Lahijani That snippet changes the engine for tables, but there are other things need to be changed of InnoDB when using utf8mb4: https://github.com/processwire/processwire/blob/341342dc5b1c58012ae7cb26cffe2c57cd915552/install.php#L958-L969

A php setting can never override what htaccess does. PHP is not even started when the htaccess file is read/executed.

I've read that one a few weeks ago and while I like the gist of it I find it horrible that the javascript community just seems to replace complexity with even more complexity. Also such blog posts always seem to be about the technical side of keeping js in check, while I feel the biggest gains can be archived by actually doing less in javascript. I'd like to see some practical advice on how to not blow through kb's of npm packages and still having a reasonable interactive website. Yesterday I tried out shopifys draggable library and even that one alone is like a third of the max. size of bundle mentioned in the article – just for drag and drop

Nobody but maintainers can reopen closed issue, but people can still comment on closed issues, initial opener or not. I cannot confirm that specifically for the processwire repos as I'm a maintainer there, but that's the behaviour I see on other repos on github.

The only sane approach to issues on github I know is closing them as fast as possible, which can be split up into subtasks by deciding if something is a … bug => fix as fast as possible/fitting and then close directly. If there are still things to clarify this can be done in the closed issue. ryan can open it again if really needed, but it's ryans task to say "this issue is resolved" by marking/keeping issues closed. Keeping that responsibility on the issue openers side simply does not work from my experience. feature_request => should be closed immediately with a message to where feature requests should be stored not a bug => closed immediately not reproducable => ask for failing test/repo/something, close if there's no response after x (2-4) weeks

I just quickly pulled an older image out of the support forums. This is how the inline editing looks like. It's simply rendering the inputs you normally see in the page editor when you click to edit a certain row. I'm not aware of any "multi row per result item" setting like for ProFields: Table.

I'll leave this here as well. Might not be a good for product variants, but generally it should be evaulated to use pages before moving stuff into a single page:

Class and function names are case insensitive in php.

That's just the collation, but not the charset. You need to change at least the latter one. https://dev.mysql.com/doc/refman/8.0/en/charset-general.html Edit: I'm also kinda wondering about the "but for title and descriptions" part. Why not use utf8mb4 for everything, which is the way to actually use utf8 text in mysql. The "utf8" charset is just plain not utf8 at all, but rather a mysql abomination.

Wordpress has one thing different than ProcessWire, which enables them to have such a high quality default theme: Just three types of data, where two are quite similar. It‘s post, pages and comments. The rest is wysiwyg content all the way. In Processwire we don‘t have that and the power of it comes from not having that. Wordpress themes are just pretty frontends for a nearly non changing backend structure, which it had for years. In ProcessWire the first thing you probably do is creating your own content types (templates) and that‘s what no default theme can cater for. How should it know how to display that random blob of data you decided is a entity in websites domain? So there‘s not much incentive to spend a great amount of money on a high quality theme, which is unusable for just about any reasonable usage of processwire beyond „first impression“ after installation.

Should be solved by this update:

I'd suggest using a file field for the tiff and on upload trigger the conversion of the image to a jpg, which is then stored in a image field. For the actual conversion I'd look outside of processwire, so you can scale independently or even more the conversion to a beefier node if needed.

The unzipping behaviour is part of the inputfield itself not the PageFiles/PageImages class: https://github.com/processwire/processwire/blob/341342dc5b1c58012ae7cb26cffe2c57cd915552/wire/modules/Inputfield/InputfieldFile/InputfieldFile.module#L943-L945

There's lots of tooling and services available for po/mo files though. People might not want to translate things manually if there are ways to outsource or automate that task. So not needing to touch the JSON files is not necessarily an advantage.

Afaik that distinction is just one some frameworks use. The js api doesn‘t do that.