Jump to content

BillH

Members
  • Posts

    221
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by BillH

  1. 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
  2. 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?
  3. I don't know if it's in the documentation anywhere. I just somehow knew from experience!
  4. 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.
  5. 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!
  6. 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.
  7. 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();
  8. 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!
  9. 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().
  10. 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.
  11. 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.
  12. 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?
  13. 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.
  14. 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.
  15. Creating new (or amended) actions is quite straightforward, and there are good instructions on the module page. Good luck with getting it working!
  16. 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.
  17. 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.
  18. 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).
  19. 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.
  20. Might these posts give you some starting points?
  21. Might a Select Options field suit your needs? Part of the core, and can be suitable for uses such as you describe. Details at https://processwire.com/docs/fields/select-options-fieldtype/.
  22. You may find an answer in this discussion, which has a number of suggestions and links: It might also be worth checking that you haven't run out server space.
  23. Welcome to the forums! There's a good chance that the cause of this problem is the same as that for the issue in your next post (Uploaded file showed up with 0kb size), so I'd suggest resolving that first. I'll post a response to that second post shortly...
  24. 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) {
  25. 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.
×
×
  • Create New...