BitPoet

Something like for($i = 0; $i < $imagesCount; $i++) { $img = $p->imagesMain->eq($i); $descr = $descriptionsFiltered[$i]; $img->description = $descr; } ?

That's a remnant from times with PHP < 5.4, where the register_globals setting in php.ini was still often set to true. This meant that every GET or POST parameter was added as a global variable of the same name. If programmers were just a tiny bit sloppy and forgot to initialize their global variables with reasonable default values, this lead to security issues since malicious visitors could set their desired values. A simple example would be a PHP script with an authorization check. Let's suppose our hacker calls it with the URL http://my.broken.site/page.php?auth=1 <?php // Authorization check if(is_user_authorized()) { // we only set $auth to a truthy value when the check was successful $auth = true; } if($auth) { show_sensitive_content(); } In that example, $auth isn't set to anything if is_user_authorized fails, so our hacker created a global variable $auth from the GET parameter with a truthy value (1) and that never gets overwritten. He can see our sensitive content. Ouch. To prevent these kinds of problems, it was good practice to remove all globals before populating your own.

From the top of my head: I've built a small schema for OSS that has the following additional fields: PW language name groups (multivalued) page id type indicator field for file or page to limit results to one of those if required an additional file classification field to search for special documents (e.g. process instructions, sales catalogs...) In a save handler, I call my search update routine that: removes all entries in OSS for the current page id includes the search engine update logic for the current template that in turn: extracts the content extracts information on all files that should be in the search adds a search entry through OSS' REST API for each of those for each language with page id, language, type and all permitted groups My search routine then only needs to pass the current user's groups (from @apeisa's essential UserGroups module) and optionally the language to the search API as facet filters to get permission-filtered results. I'm in the process of moving the actual update action to background batch jobs since the number of files and their sizes are constantly growing, slowing down page editing. This will have the nice added effect that I can run the updating logic on one or more different servers by sharing the file system between them. And, of course, there's a script for worst cases that runs through all pages and builds the search index from scratch.

It's a mixed approach. I use page-per-file to inline our most important process documentation PDFs enhanced with keywords, tags and meta data, most with all the niceties of built-in multi-language support. Our construction pages make heavy use of my MediaLibrary module for images and shared reference docs. A lot of department docs are added to simple file fields, and, to round everything off, version critical files (like technical drawings) stay on our network shares but our editors can easily add links to those through custom built CKEditor extensions. There's a bit of tag and save handler magic as well as prepend scripting going on so these files (and ones resting in the DMS) are available through URLs (either segments or get params), permissions are honored and they can be found in the search.

Nearly all of my projects are intranet solutions or limited-audience web applications rather than web sites, so my top requested features differ a bit: Sufficiently fine-grained permission system (check) Drag & drop support for files (check) Multilanguage support (check) Approval process (currently testing that with ProDrafts ) Interfaces to third party software (Active Directory, SAP, time keeping software, DMS etc., check, all of those easy to integrate with a few lines of code ) Sign in using credentials from above software (check, just a few lines...) Advanced search that supports (Word, Excel, PDF...) files and honors permissions (done with UserGroups and OpenSearchServer)

For completeness' sake, even though I agree that using a field that is limited in range may not be the best idea, here's how it should work without abusing ids: // Retrieve possible options through the field's typ $field = $fields->get("progress_status"); $progress_options = $field->type->getOptions($field); // Find the correct SelectableOption object by its desired value and assign it $page->progress_status = $progress_options->get("value=" . ($page->progress_status->value + 1)); Each SelectableOption object is made up of a (random and unique) id, a value (that's what you search for and assign) and a label (what the user sees in the select/radio/checkbox input).

There's no change in referencing. A PHP variable referencing a page is always an in-memory object. When you call $page->save() for the first time, PW executes an INSERT on the pages table and populates that page object's id with the last inserted id. last_insert_id is scoped to the current database connection, so other PHP threads / browser sessions inserting pages can never influence each other. There's no need to worry.

Why not? It's not that much work and provides you with all the niceties of language support. Drop a simple PHP template in the regular templates folder: <?php include("../site/ajax/{$input->urlSegment1}.php"); and create a template with url segments enabled with pattern: regex:^[a-zA-Z0-9]+\.php$ A single, hidden page can then route all your ajax calls in a language-aware way. Altogether that shouldn't take more than five minutes.

You don't need to include PW multiple times, just construct a new ProcessWire object with the path and URL of each site, then access PW's globals through the relevant site's object, i.e. $site->pages instead of $pages, etc. See https://processwire.com/blog/posts/multi-instance-pw3/ for details.

After verifying the login, you can do $users->setCurrentUser($loginUser); Afterwards, $user->isLoggedin() etc. should behave as expected. Setting the user "guest" as the current user (that part hasn't been tested by me) should accomplish the same after a logout.

Does your hosting allow outgoing http connections? Perhaps try it with a short, PW-independent php script that does a file_get_contents on a publicly reachable url.

PHP's path-related functions return the native directory separator between directories. Since the backslash is also the escape character, it has to be escaped itself to be recognized as a backslash, hence the double backslashes. The backslash in front of the forward slash, while it does no harm, isn't necessary.

It should work. I'm using an identical rule in web.config for multiple sites, and passing query parameters to PW's root url works fine. Did you try to output $input->get->id to see if it's populated?

That's likely the reason. Using the generator method instead of the normal constructor to create the user object should work, though I haven't tested it: $u = $clientbp->users->newUser();

Since the ProcessWire Rewrite rule has appendQueryString set to true in your web.config, this should work. Is the main page using a different php template that lacks the necessary includes perhaps?

Could you explain a little more what you're imagining? I might have a few ideas, but I don't want to send you on a wild goose chase. I'm not completely sure if I understand the "swappable" part right (select different ones or just reorder?). Are these widgets/areas supposed to be individual to each page they're on or (what widget means to me) shared between pages?

Populating a hidden "sort path" field computed from a page's parents in a saveReady handler should solve this. If your categories are sorted alphabetically, just store the full path, if not, assemble it from the parents' sort values with every value sprintf'd to identical, zero-padded length so alphanumeric sorting works.

That would have been my guess as well. Nine out of ten times, session fingerprinting is the cause of such problems, especially with corporate networks where outgoing IP addresses may change on the fly and security solutions might change request headers to make tracking harder.

Only the bits and pieces I picked up in forum discussions. A search for "uncache" brings up some interesting topics, mostly about manipulating large numbers of pages through the api.

Does uncaching the parent page fix it? $pages->delete($pages->get('/parent/child')); $prnt = $pages->get('/parent'); $pages->uncache($prnt); $pages->delete($prnt);

In a similar scenario, I update a free ticket counter field on the event page whenever a booking is made. This works for both solutions and enables a blazing fast search.

Yes. PHP's "if" affects the immediately following statement or block, so both versions are fine.

That's strange. Which PW version are you running? Could you try moving the sort=random and start=0 to the end of the selector string and see if the error still comes up?

You don't need to touch any core files, just create a file named "ready.php" in the site folder and put the code there. You can read up on the files for site hooks here.

That, and it should be $image->size(), not resize().