BillH

This increasingly sounds to me like a cache issue – perhaps some cache on the server, or maybe browser caches aren't clearing as expected.

To help find out if caching is the issue, I'd suggest renaming the include file to see if that makes a difference.

If it doesn't, try (temporarily) putting the code from the include file into the main file.

Just a thought, but might you have been logged in as different users with different roles/permissions in each browser, and the template have particular access set up?

You have two issues to deal with:

1. Giving users access to their pages, showing them the relevant links, menus choices, etc (and not any others).
2. Preventing users from accessing pages if they happen to find out or guess the URL of those pages.

For the first of these, you don't need either of the modules you mention. You present only links to the correct pages (and no other links), and you could achieve this using something along the lines described in my previous post.

For the second, you could perhaps use one of the modules, but you could also write your own code at the top of each template, maybe something like this:

// Assuming the root page for each user has the template "user-root",
// it's below the home page, and is name with the user's name

if($page->parent("template=user-root")->name != $user->name) {
	if($user->name == "guest") {
		$session->redirect("/");
	} else {
		$session->redirect("/$user->name");
	}
}

Let me know if you need more explanation or examples.

Have you read the page https://processwire.com/docs/multi-language-support/multi-language-fields/ and particularly the section "Multi-language field values"?

I think it'll tell you what you need, and the example code is really helpful.

This might be the link that @kongondo is thinking of:

https://processwire.com/blog/posts/processwire-3.0.71-adds-new-core-module/

I'd suggest that there are very much easier ways to go about things than using multiple databases.

I can think of various possible approaches, but I might go about it something like this...

You might have a set up like this, with the user pages below the home page having the users' names (to keep things simple for this example):

home
|____user1
|    |____page1
|    |____page2
|
|____user2
     |____page1
     |____page2

To work with the pages for the current user, you could get the pages thus:

// Get the user name
$userName = $user->name; // e.g. 'user2'

// Get all pages belonging to the user
$userPages = $pages->find("has_parent=/$userName");

// Get page2 belonging to the user
$userPage2 = $userPages->get("name=page2")

An important thing to note is that in the above example $userPages is a PW PageArray (https://processwire.com/api/ref/page-array/), and you can work with this instead of with $pages (i.e. all pages).

To deal with a superuser, you might do something like this:

if($user->isSuperuser()) {
    $workingPages = $pages; // All pages
} else {
    $userName = $user->name;
    $workingPages = $pages->find("has_parent=/$userName"); // As in the previous example
}

I've kept things simple here to illustrate the idea, but I imagine your set-up would be a lot more complex. But I hope this helps as a starting point.

As far as I know, your text_article custom field should work without problems (so long as it's not a CKEditor field, which won't work as a custom image field).

The only thing I can think of right now is checking that you haven't got a maximum length set on the field (Input tab).

If you need text formatting in your articles (which seems likely with long text) and don't want to use Markdown, you'll need to use some other approach anyway. If there will always be just single images on your page, you could simply add a field to the page. But if there could be more than one image, you could use a Page Reference custom field and store each article in a separate page.

If your URLs are within the PW site (and it sounds as if they are), then a Page Reference field is probably the best option – as it would be for a single-language site too!

But if you do need multi-language URL fields for some reason, you could have two URL fields set up as language-alternate fields, as described at https://processwire.com/docs/multi-language-support/multi-language-fields/#language-alternate-fields

I don't know, but it sounds as if it might be some sort of caching issue.

Do you have template caching turned on anywhere (look on the template's "Cache" tab)? Are you using any other sort of caching in ProcessWire that you're aware of? Is there caching on your server?

I don't know if it's in the documentation anywhere. I just somehow knew from experience!

If a user has permission to access one of the modules under your Tools menu, the Tools menu should automatically appear for that user.

So, in your module, you might have something like this:

public static function getModuleInfo() {
    return array(
        'title' => 'Test Module',
        'summary' => 'Module to test permissions',
        'version' => 1,
        'permission' => 'test-permission',
        'page' => array(
            'name' => 'test-module',
            'parent' => 'tools',
            'title' => 'Test Module'
        )
    );
}

Then if the module is installed and the user has a role with 'test-permission', the Tools menu (and of course the Test Module item) should appear.

This is a slow bit of reporting back, but it might be useful for anyone who comes across the same issue.

In brief, the problem has gone away, but I don't know why.

All I did was follow @horst's advice and look at the "sort" column in the database. I watched the column changing and made a couple of manual changes to discover how it worked... And then found that the bug had gone way - and for all pages where it had occurred. Several users experienced the bug, but they have now been using the system for several weeks without it recurring, so it seems to be fixed.

I don't like leaving an issue without finding out the root cause, but I haven't been able to work anything out. If sombody has the same issue, try what I did and keep your fingers crossed!

Welcome to the forums!

There are various ways you could do this, if I understand what you're trying to achieve correctly, but I'd suggest something like the following (written without any testing):

// Get a ProcessWire page array of pages with the X metric
$testsWithX = $pages->find("repeater.metric=X");

foreach($testsWithX as $test) {

    // Set output formatting to false
    $test->of(false);

    // Get the relevant effect from the repeater
    $effect = $test->repeater->get("metric=X")->effect;

    // Set a sort property for the page (in the page array)
    $test->effect_for_sort = $effect;

    // Save (to the page array)
    $test->save('effect_for_sort');
}

// Sort the array of pages
$testsWithX->sort('effect_for_sort');

Looping through the pages shouldn't give you any issues with performance at all - unless you have a huge number of pages.

One alternative would be to maintain a sort field (containing the relevant effect value) on each page, kept up to date by hooking on page save. Then you could get the sorted array of pages with a single selector. However, something like the above should be fine – and would in any case be a better approach while developing the site because it's easily amended.

I didn't think of pagination! You could make the last line a find() and, though I haven't tried this, you might be OK.

$limitedResults = $allResults->find('limit=15');
echo $limitedResults->render();

One method would be to combining two finds, something like this:

$results = $pages->find("search_index%=$query, has_parent=1234");
$moreResults = $pages->find("search_index%=$query, has_parent!=1234");
$allResults->import($moreResults);
$limitedResults = $allResults->slice(0, 15);

Note that setDuplicateChecking() can be useful with import() when doing this sort of thing.

Perhaps someone else knows how to do this with a single selector!

If you want dates to output in other languages, I'd start here:

And perhaps also look at this:

If you want all dates from a particular field to be formatted the same on output, look at the Details tab for the data field.

To format dates on a template, use PW's $datetime->date() (see https://processwire.com/api/ref/wire-date-time/date/).

Or you could get the timestamp (the unformatted date) with $page->getUnformatted("date_field") and then use PHP's date functions – particularly strftime().

If I'm understanding what you're trying to achieve correctly (which I may not be!), might something like this work?

$twoDaysAgo = strtotime('-2 days');
$twoDaysAhead = strtotime('+2 days');
$pagesInDateRange = $pages->find("template=templatenameA, datefield>=$twoDaysAgo, datefield<=$twoDaysAhead, sort=datefield");
foreach($pagesInDateRange as $pageIDR) {
    if($pageIDR->type == 'season') {
         // Using just two generalised field and variable names as an example
         $var1 = $pageIDR->field1;
         $var2 = $pageIDR->field2;
         $relevantPages = $pagesInDateRange->find("template=templatenameB, fieldA=$var1, fieldB=var2, sort=datefield");
  	} elseif ($pageIDR->type == 'solemnity') {
        // etc etc
    }
    foreach($relevantPages as $rPage) {
        // Render pages
    }
}

This could all go in the template for the page.

Many thanks @horst, that's really helpful. I wasn't aware of the "sort" column.

All pages use the same image field. The pages use three different templates, but the problem occurs in the same way with all three templates, and the field settings are the same on each template.

I'll investigate following your suggestions and report back.

After manually re-ordering images in the back end, when the page is saved, the images revert to their original order:

• Starting order: A B C
• Manually re-order: A C B
• Save, and the order reverts to: A B C

This does not happen on all pages. Notable, newly created pages don't seem to have the problem (though it's possibly being newly created isn't the issue).

Various other things have changed over time with the image field in (the biggest one being introducing custom fields), so it is possible that reason some pages are affected and not others is connected to when the page was created – but this is a total guess.

The issue may have started on updating to PW 3.0.184, but I'm not sure about this.

I'm not sure where to go next with this. Does anyone have suggestions for causes of the problem or ways to go about debugging?

3 hours ago, mikeindee said:

BillH - thanks for the explanation of putting random text in the .htaccess file. That makes sense when explained. So I tried random text in the .htaccess file that is in the /var/www/html/pwire/ directory. Restarted Apache; cleared the cache and tried loading. Nope - loaded the page a treat! So then I tried the other .htaccess file that is in /var/www/html/pwire/site/ directory (and recall that pwire is the directory I set up for PW). Same thing. So does this indicate that neither are being 'read'? And if so - why? And which is the 'important' one? Or are they both important?

The main PW .htaccess file is the one in your /pwire/ directory.

The .htaccess file in /pwire/site/ is, as I understand it, just there to protect certain files if the main .htaccess is missing – and though I haven't tried, I would guess the PW installation would work without it.

You ask about the method of writing gibberish into .htaccess that @elabx mentioned. The technique is to write a few random characters into the top of .htaccess, and then see if you get a 500 error. If you don't, .htaccess is not being read.

Creating new (or amended) actions is quite straightforward, and there are good instructions on the module page.

Good luck with getting it working!

Just a thought, but it would probably be quite easy to make a copy of the Import Batch Users action and amend it to handle duplicate names in whatever way you want.

It might be as straightforward as replacing the code that issues the failure message with code to loop through the array of new users and deal with duplicates.

I think that the "Import Batch Users" action of the AdminActions module will do what you want.

You can assign multiple roles to the users and add values to multiple fields. You paste in CSV or JSON.

You'll probably find what you need under "How to force pages to sort by their admin order with $pages->find()" on https://processwire.com/docs/selectors/

If that doesn't help, you may need to loop through the pages (or set up a sort field, but that'd most likely be greatly over complicated).