Jump to content

BillH

Members
  • Posts

    221
  • Joined

  • Last visited

  • Days Won

    4

Posts posted by BillH

  1. 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?

     

     

  2. 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.

     

    • Like 2
  3. 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!

     

     

     

    • Like 1
  4. 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.

    • Like 2
  5. 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!

    • Thanks 1
  6. 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().

    • Like 1
  7. 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.

    • Like 1
  8. 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?

  9. 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.

    • Like 1
  10. 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.

    • Thanks 1
  11. Welcome to the forums!

    I'd start by checking the search form, particularly as rendered in a browser. Does everything seem OK, and in particular, is the value of the 'action' attribute as expected for the search page?

    Another possible cause might be caching, so if caching is on for the search page I'd turn it off (Templates > name-of-search-template > Cache). And if you have any other sort of caching running, you could try with that turned off too.

    • Like 1
  12. One possibility is that the pages are hidden, unpublished or no-access, which are ignored by default by $page->children.

    Try adding an 'include=all' selector to see if the material from the pages then appears:

    foreach($page->children("include=all") as $child) {	

     

    • Thanks 1
  13. I'm not sure that I fully understand what you need to do, but I have a couple of thoughts.

    One is that runtime fields and searches won't mix well, and if you need to maintain a field for some kind of sort code, you'd be better off hooking on saveReady to maintain a field.

    The other is that it can be quicker than you expect to loop through the results of a search (so long as there aren't huge numbers). So a good strategy might be to get as few pages as possible using selectors, and then loop through those pages to produce the final result.

    • Like 1
×
×
  • Create New...