LostKobrakai

"it" is the GET parameter, what acts as access-point to ProcessWire. All requests are rewritten by the .htaccess file to something like this: yourdomain.com/index.php?it=/subpage/moresubpages/test (see here) Therefore it's strange that this index is undefined. It's one of few necessities in pw.

Maybe it's that part: http://processwire.com/api/multi-language-support/multi-language-urls/#getting-started

In the php.ini short_open_tag=On http://php.net/manual/en/ini.core.php#ini.short-open-tag

That's by design. You can drag and drop the whole row (exept on the link in the first column, which has to open the modal). But it looks like you're using PageTableExtended and I don't know how much this behavior is changed by it.

Your ping comparison is flawed as 50 requests wouldn't lead to 2sec difference. 50 request with 45ms difference would result in about this: 45ms (initial request) 45ms * 49/4 (about 4 concurrent connections to single domain) ----- 596.25 ms So the 45ms add up to about half a second, depending on server/browser. And 50 requests is not really a small number in that regard. Throw in a second domain – own or external cdn or even simply a second subdomain to the same site – and you'll get double the concurrent requests.

The answer is quite simple. flush(); ob_flush(); Use these as soon as you have parts of "final" markup, that you can send to the user. Sadly this needs to be in order, so most of the time it's more like: "header" - flush - "content" - flush - "footer" - end This speeds up every request. Other options are caching and faster servers (and/or cdn). It doesn't necessarily need ProCache for fast caching. TemplateCache and MarkupCache are quite powerful, too, but they do require php to run (fast servers *hint*).

Also try to add a return at the end of the file. I seem to remember that some OS's can't handle files well, which do not end with one.

It's using ProCache with CloudFront as cdn.

I decided to not use version control for this project as this happened in the try out phase. Renobird's ActivityLog was a light alternative in this case. Therefore I can't follow up on your concerns before I'm a little bit less busy.

The above code is basically the same as the previous posted one, the first does only save specifically the password field and the other one all changed fields. As you've pointed that you're quite sure previous passwords should have worked, too, I'd think there's something else going wrong. Could you provide you're ProcessWire version and any installed 3rd party modules? Also could you please check for the existence of an userSaltHash in site/config.php, just to rule out issues with that. Please do not post the value, as this would potentially be a security risk for your site.

https://processwire-recipes.com/recipes/resetting-admin-password-via-api/

Also quite useful: When hooking ProcessPageEdit the edited page is $event->object->getPage();

This is even better as it's using less or at least more optimized database calls (depending on the exact selector): $events = wire('pages')->find("parent=/events/, event_start_date>today, sort=event_start_date");

Here you'll get a quick overview over the common caching options in processwire: http://www.flamingruby.com/blog/processwire-caching-explained/

It's possible but not automated. A siteprofile is just a bunch of template files and a sql file with all the templates/fields set up. Merging the files should not be difficult and for merging the database I'd suggest using a fresh installation of the blog profile and then export/import fields/templates over. The fastest way to recreate the base structure of the pages is most likely doing it by hand.

For me "<=" is just not working with radio buttons, but it works with a selector like this: "pricelistselect=1|2".

Both of those should work. $page->select = 1; $page->set("select", 1); P.S. Remember to save everything in the end.

Does it work with "pricelistselect=2"? Maybe it's an issue with the "value|label" format.

Under Pages > Find in the backend you'll find a quite powerful search area. Just choose something like this "template=yourTemplateWithTheSelect, select=1". Also have a look at FieldtypeOptions. It's a more powerful core alternative to FieldtypeSelect with less overhead than having pages.

The frontend isn't the only place where you can cache stuff. For me it just took 40 seconds till I got the html response, while the bulk of other requests was done in another ~7 seconds. I don't know what this page is doing, but caching the generated markup to prevent it from doing it on every request will get you a huge speed boost. With all the static files served this fast maybe even ProCache would be a good investment.

Are the first two "Selectable Pages" subfields empty? If so than please provide the ProcessWire version you're using.

Is is possible to disable this file manager, at least temporarily or in a cloned installation?

There where already lots of other topics about handling content-blocks. Also please have a look at PageTableExtended.

Please do post the modules, which do in any way handle files. Also there should not be need to run a dev version with a fresh 2.6 stable version.

You don't need so set a parent, just use a single selector: id|has_parent=1, include=hidden|unpublished|trash|all For the "include" part choose one of the values. Depends on your exact needs.