LostKobrakai

For resizing an image the whole image needs to be loaded into memory (at least for gd lib, which is used by processwire until now), therefore it's expectable to hit a limit of 3MB/s when needing to read a file of more than three times that size. Even on a dedicated server there can be speed or memory issues with this kind of image sizes. So you either need to think about if shared hosting is the correct environment or if you could limit down the size of the images to be processed. The latter option could be manual or automatic client side shrinkage of too big images. If you still need the original images you'd want to store them in a file field instead of an image field. This will prevent that thumbs are generated from the big image. Yesterday ryan did push an update to the pw 3.0 branch, which added the possibility to use other image processing libraries than gd, which might be more catered to processing big images efficiently, but depending on the shared hosting these might not be available.

Iirc there's a pull request on the github repo of ryan, which does add recursive hanna code rendering. It's not possible with the unmodified module.

Anything, which is dependent on the time should not be stored anywhere, as it's potentially invalid minutes later. Calculating these at runtime is easy, but for db selection you'd need to build a custom selector or completely switch to raw mysql queries.

Check the xhr requests if the needed header is really present. If not it won't be recognized by processwire. Being a xhr request alone is not detectable for the webserver.

@pwired There's nothing fancy about it. I've a small process module as well, which does the execution of the functions as well as storing which migrations are migrated and which aren't. // Migration.php abstract class Migration extends Wire{ public static $description; abstract public function update(); abstract public function downgrade(); } // 2016-03-03_18-27.php class Migration_2016_03_03_18_27 extends Migration { public static $description = "Update Homepage title"; public function update() { $this->pages->get('/')->setAndSave('title', 'Super fancy new Homepage title'); } public function downgrade() { $this->pages->get('/')->setAndSave('title', 'Home'); } }

This is really nice for gitlab.com, which can sometimes be quite slow if you want to dig into some folders.

The ___execute* functions are already depending on urlSegments. To pass data around rather use GET or POST data.

Vagrant does have a payed (80$) plugin for vmware. Otherwise you'd need to use virtual box or leave use other provisioners like ansible or chef instead of vagrant.

I'd say you're most often looking for orders of a user, so I'd add a page field to the user template, where all orders of that user are added to. Then you can always call something like $user->orders->find("price>50").

Database migrations are "better" supported in other frameworks because they wouldn't function without them. A laravel framework doesn't have any databases beside those setup by migrations. But these are actually really bare bone in that they mostly update schema changes. For migrating db rows most use database seeding libraries, which then create the necessary models to be stored. Both can be done with the processwire api without actually needing to learn something new. This is basically what model factories do in frameworks (besides the autofill functionality). $pages->add('basic-page', $pages->get("/url/"), 'profile', array( "someField" => "value", "anotherField" => 202 ); And this may be what migrations do. // Create field $f = new Field(); $f->name = 'text'; $f->type = 'FieldtypeTextarea'; … $f->save(); // Add to template $bpt = $templates->get('basic-page'); $bpt->fields->add($f); $bpt->fields->save();

That sounds exactly like the things I've read about suhosin by now. And I've always wondered, why this thing is still alive.

Ah. It's probably because of the namespacing in PW 3.0 http://code.runnable.com/Vtcay97VO6lCfjAD/case-sensitive-class-test-for-php Edit: OK, strangely the published snippet doesn't throw. So I'm not sure about it.

You probably shouldn't store site content inside the Admin folder, as there are various pages, which are hidden, not viewable by non-superuser and such things. So you'd need to use include=hidden or check_access=0 just to make things work. I'm personally not a fan of this, as any errors made in selectors could lead to being a security hole. I'd rather use a page-field to link users to orders and store the orders under a different parent outside of the admin branch.

Actually php isn't case sensitive in terms of class names, therefore both should work. But still WireTempDir feels to be less prone to errors coming up.

I'm using simple migration scripts, where I update anything via the api. It's a bit verbose and not as nice as using the backend, but it keeps db changes in a manageable and documented fashion. Also after a while it's more copy paste for most tasks.

If someone really needs lots of free emails (100.000): https://www.sparkpost.com/pricing And a blogpost regarding future plans https://www.sparkpost.com/blog/my-promise-to-developers-sparkpost-pricing/

I'm always doing a save() after removeAll() as this does also prevent any naming collisions (no more -1). And I'd also suggest not using the page files path to create files in. Rather use wireTempDir().

The question is, if progress bars are really worth the hassle of a multi step form. Also you could always put files in a temporary folder via plupload and submit the form just with the filenames / path via a traditional submit, where you don't upload the files, but just add them to the page by the submitted path / filename info.

Workers are separate processes, which run alongside your webserver stack on the host system. They can process things they get out of the queue without being reliant on the Request->Process->Response cycle of the webserver. E.g. You want to have a way for users to request a big report on your website. As a big report sounds like, it take some time to generate the pdf for it (say ~1 Min). You wouldn't want your user to sit around and watch the nice browser spinner, waiting for the next page to pop up. You can now write the request in a queue and instantly return a message stating that the report will be generated and emailed to the user when ready. To generate that report you may know the option of using a cron to trigger website logic, without an actual user requesting a website, but that's also flawed with things like timeouts and such, also it's only starting in intervals. That's where workers come in. These are php (and other script) processes, which often run as services like e.g. your apache server does. These scripts contain some way to not exit early (e.g. infinite while loop) – which is the biggest difference to website request – and periodically check their queue if there's work to do. If your report request is in it, they generate the pdf, email it and if done delete the queue item. If there are other reports to do they'll move on to them, otherwise they sleep until another queue item is available.

That's exactly what I tried to tell you above. As long as you're not using javascript to submit the form without page reload you simply cannot have upload bars. Submitting a form does trigger by default trigger a page-reload, which is not observable by anything javascript. If you're not handling the full form submittion via ajax, you've to separate the steps of submitting the form and uploading files. You could potentially manage to have the files uploaded via ajax on hitting submit, but before the form is sent, but there's no page to upload files to before the form itself is sent.

The $pages->count() does work? If not than it would be nice to investigate this further, because it should return the same as counting locally.

Can you post the selector for that? Also in which context do you have that issue (module, template or bootstraped)? Irrespective of that issue, you wouldn't want to load 300 pages (fully with all their field values) just to count how many you have.

A quick option could be a pre-build LAMP instance on digitalocean. It's created in minutes and payed on demand, which is probably a nice thing if you're just testing stuff out. And I want to support adrian. I've only read bad things about suphp and suhosin.

All the $pages->find() calls are evaluated while creating $stats, which in turn means $stats is not defined at that moment. If you want the count to run "on-demand" you'd need to look into using anonymous functions. Also using $pages->find()->count is most of the time an anti-pattern. If you're not using those pages, but only the count rather user $pages->count($selector). The latter does only count the pages in the db, whereas your version does load all those pages and does count them in memory (php). Edit: Just to make things more clear about the array creation. You're building up an array and after the whole array is computed – with all dynamic calls being evaluated to static values – you're saving the data into the variable $stats. You could go another way like this: $stats = array(); // Create array; $stats !== undefined $stats["total"] = array( ["main"] => array(), ["yes"] => array() ); // Update each value one at a time $stats["total"]["main"]["selector"] = "template=50, parent=$formSuperSelector"; $stats["total"]["main"]["count"] = $this->pages->count($stats['total']['main']['selector']); …

If a cookie consent is really needed is a questions for lawyers, but I've also read that the law should (at least in theory) only be applicable to cookies, which are not critical to the websites functioning (login/carts). Anyway, I'd say that's not the topic to further discuss here.