LostKobrakai

I've switched to writing all changes affecting the db in migration files (simply using the pw api), which I can easily re-run on any other server. Took a lot of the pain away for me. It's otherwise not possible to automate db changes with servers, where content is independently created (e.g. overlapping id's). Additionally it's not limited to fields/templates either. I'm not sure if your half way automatism will actually improve your workflow. You've still to update any added field data as well as any (even if rare) schema changes, that might have happened to tables. If you're sure you'll only be adding fields (without data) than it should work.

There's http://lightning.pw, but it seems to be mostly abandoned.

Is the server running php 5.4? This does suspiciously look like a 5.3 install, which doesn't support short array notation with [].

https://processwire.com/talk/topic/12147-continuous-prevnext-links/

You could use https://github.com/blueimp/jQuery-File-Upload to upload the original file only for storage purposes (File field, otherwise the admin thumb will be generated) and an additional client side resized version, from which you then generate your needed thumbnails on a much lower overhead.

Yeah. I corrected my post.

Can you define "not much visitors" a bit more detailed. If there are only a handful of people on the site these errors would rather suggest there's something not right on your website instead of an issue with your host.

Any reason, why you need a server to run this site? ProcessWire should normally run fine on most shared hostings as well.

That's the easiest option to start adding hooks. https://processwire.com/blog/posts/processwire-2.6.7-core-updates-and-more/#include-hook-file-example If that's getting unwieldy to manage/overview, then you can go ahead an create some modules, which group related hooks and make them easier to reuse.

Just a small addition. ProcessWire does provide a pdo instance as well: $database vs $db (mysqli). @FBachofner You can probably take most of the code from FieldtypeSecureFile and you'll see how FieldtypeFile can be extended. You'd want to do mostly the same, but instead of rendering files from a non-webroot folder you'd render files from the db.

If the hackers are as good in hacking as in designing websites, then certainly not

Ah, sry wire('all')->toArray() or wire('*')->toArray() will get you the part you want. Might be because of the changes to the wire() function call to allow for multi instance. I've just looked into the 2.7 core files and the keys 'all' and '*' are also present there. I'm not sure for how long these are supposed to be used as replacement for fuel() calls.

The first thing to understand is, that real progress bars are not possible when using standard html forms without any javascript involvement, as the files are uploaded after a form is submitted, after essentially the current page is "left behind", but before the actual site reload with the response data from the server. That's why you need some javascript/ajax upload to get progress bars. If you're currently not using any ajax logic this might bring some need of refactoring on the server-side as well. And that's also the reason why WireUpload is not really the part to ask for, as it's only responsible of handling already submitted files on the server. How files are send to the server doesn't matter for it.

Replace 'fuel()->getArray()' with 'wire()->getArray()' and it should work. fuel() is already marked as deprecated for a good amount of time.

That's probably not possible without hooking somewhere in the cache. The template cache does probably only store the content, but not any headers, which can be desired or not desired.

If you're using a dedicated template (not urlSegments) you can set the content type in the template's settings.

You don't need anything extra. Just __(); and that's it. Also all of these calls need to be on a single line in the file, which no other multi-language __() call.

@Werner ProcessWire does not control the data structure as well as the output of your website. This is very different to a blogging website like Wordpress, where content is very much determined upfront. If you need AMP you'd need to implement it yourself. But ProcessWire is fully equipped to do the thing the wp plugin does. Allow urlSegments for your templates and allow 'amp' as urlSegment. Then you can use this to output the amp code in your template: if($input->urlSegment1) { // add "&& $input->urlSegment1 == 'amp'" if you've more urlSegments // Output AMP } else { // You're previous template code } Your url www.example.com/some/site/ will be the normal page, www.example.com/some/site/amp/ will be the amp site. I'm just not sure how google is supposed to know about this amp website in the first place.

Here's where the link and it's url is defined: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Process/ProcessPageList/ProcessPageListActions.php#L38-L93

A webservice is in no way different to a normal website besides the fact that it's returning different data, e.g. json instead of html. Build it like you normally would, but let the template output json. You just need to be aware, that the usage of sessions and session cookies, which power the authentication in processwire, are not the best option for webservice authentication.

I'd suggest just adding a new field to the language template (show system templates in the template list) and putting the iso codes there. Then you can just do $language->iso or similar. That's nothing that should depend on any settings on the homepage. Also there's $language->isDefault() if you need to change any logic only for the default language.

Changing only parts of a page is javascript territory and therefore not a ProcessWire topic. I'd suggest looking into ajax and especially the pjax implementation, as it's quite simple to get started.

Afaik wireRenderFile does just do a "extract($vars)" to populate the local variables. There's no need to sanitize or otherwise limit data input.

I'm especially worried about the pricing model. It seems like it's another step in upping the monthly costs.