LostKobrakai

PW-Moderators
  • Content count

    4,601
  • Joined

  • Last visited

  • Days Won

    92

LostKobrakai last won the day on June 20 2017

LostKobrakai had the most liked content!

Community Reputation

4,549 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

14,901 profile views
  1. LostKobrakai

    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?
  2. LostKobrakai

    @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
  3. LostKobrakai

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

    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
  5. LostKobrakai

    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.
  6. LostKobrakai

    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
  7. LostKobrakai

    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.
  8. LostKobrakai

    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:
  9. LostKobrakai

    Class and function names are case insensitive in php.
  10. LostKobrakai

    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.
  11. LostKobrakai

    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.
  12. LostKobrakai

    Should be solved by this update:
  13. LostKobrakai

    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.
  14. LostKobrakai

    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
  15. LostKobrakai

    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.