Jump to content

BillH

Members
  • Posts

    255
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by BillH

  1. One approach might be to keep a log of a certain number of timestamps for the most recent hits on each page (dropping the oldest when adding a new one). Calculating the average difference between the timestamps would give a rate at which the page is being hit. It might also work to look at the age of the oldest timestamp, and if it's less than a certain age assume the page is receiving a lot of hits. You might find some useful techniques in the Page Hit Counter module.
  2. I assume that you are talking about a user of the back end being able to change the order. The nicest way that comes to mind would be to use the ProFields Repeater Matrix (a paid module), which would allow dragging fields into order. Otherwise, I'd suggest a Page Reference or Select Options field to define the order of fields. You could use radio buttons with predefined field arrangements (e.g. 'main text / slider / image' , 'slider / main text / image', etc). It might also be possible to use AsmSelect instead of radio buttons, with each value being a field, and with preselected or default values that include all fields. However, you'd probably want to omit the delete button on each item and the selection dropdown, which could get complicated (perhaps easiest using CSS). Others may have better ideas!
  3. That's a serious amount of PW awesomeness you've provided! Bookmarked for my own purposes 🙂
  4. To implement what has been suggested by @bernhard and @BitPoet, there are modules that might help. Perhaps you could display data using the RuntimeMarkup module. And for selecting a race, the Dynamic Options module or the Dynamic Selects (commercial) module might be useful.
  5. I don't know how to do what you're suggesting (perhaps someone else can help!), but I'm wondering if it might be possible to achieve what you need using field dependencies. It might work to combine dependencies with validating fields or setting field values as discussed here:
  6. I too forgot it was only pages before a certain date, so don't miss @bernhard's suggestion! Meanwhile, I guess that deleting so many pages will cause timeouts or memory problems (I may be wrong!). If it does, you could run the code several times using a suitable 'limit' in the selector. You could do this manually, or perhaps put the code in a shell script and repeat using Cron. Or use LazyCron.
  7. The counter is correct: you still have 124019 pages. Perhaps the script is timing out or running out of memory. Try this variation of @AndZyk's script: $authlogs = $pages->findMany('template=authlogs, limit=100'); foreach ($authlogs as $authlogPage) { $pages->delete($authlogPage); } Note: findMany() reduces memory usage; 'limit' reduces the number of pages selected. (And 'authologs' is changed to 'authlogs' in two places.) Does the count now drop by 100?
  8. I notice that in the example code the selector for $authlogs is 'template=authologs' (with an extra 'o'). Did you perhaps copy that selector without correcting it?
  9. Another recommendation is the Page Manipulator action of the Admin Actions module.
  10. I've finally got back to dealing with this... And the link in my previous post does provide a working solution. Thanks @poljpocketfor your help!
  11. I think the solution may be here (applied to a repeater rather than a repeater matrix), though I'm still conducting tests:
  12. However, I've just found that $page->secureFiles() returns "true". [EDIT] I don't understand this, but I'm not sure how relevant it is, as I think I may have found the solution - see next post.
  13. "Prevent direct access to file assets owned by pages using this template?" is set to "No". I tested the other two settings, and they didn't change anything. Also, following on from your suggestion, I checked $config->pagefileSecure in wire/config.php, and it's set to "false".
  14. Thanks @poljpocket, a useful thought and I've just checked. In each case the URLs are identical.
  15. I have an area in the front end of a site that can be accessed only by logged-in users with a particular role. The page works fine for such users, except that images in a repeater field don't appear. Each image field within the repeater displays either the alt text or a placeholder (depending on which browser), but the image does not load. Attempting to load one of the images on its own in a window using its URL also fails. However, the images load correctly when the page is accessed by a superuser. It thus seems as if users with the role don't have permission to access the images. I've tried specifically giving view access on the field settings, but it doesn't help. I can't think what other settings might work. Does anyone know what I should be doing?
  16. Hi, and welcome to the forums! I suggest starting with this thread, which gives various options: Let us know if you need further help!
  17. Another option might be the RuntimeMarkup module.
  18. It occurs to me that if you want a single expression you could also use: if($page->get("field_$i") == 'test') { ...
  19. I think you have to do it like this: for ($i = 1; $i <= 40; $i++) { $fieldname = "field_$i"; if($page->$fieldname == 'test') { // do stuff } }
  20. It does seem that comparison operators don't work with image custom fields. I've just tried it with a text field and, like you, get a message saying the operator is not supported. I don't know why this is. Perhaps someone else can explain... A rather laborious workaround might be to create separate index fields that are automatically maintained with a hook on saving the article. If no better solution is suggested, let me know if you need help with this. On the bonus question, your version using OR-groups looks as if it should work, so I'm not sure what the issue is – though you might want to try 0 instead of the empty string.
  21. Selectors support custom fields for images. So, my first guess is that there's something about the logic of the selector or how it interacts with the data that is causing a problem. One thing to watch out for is that 'today' is, I believe, specifically 00:00:00 today – so, for example, '<=today' might be better as '<tomorrow', or you could create your own variable containing the particular time you want. Regarding your bonus question, I think the last point above may lead to the result you want. $pages->find('template=this_template, date_from<=tomorrow')
  22. I spoke too soon - should've checked first! I realise that I've been using CKEditor fields for this sort of thing, and they add &nbsp; entities to the start of the line. Might this be a workaround? Meanwhile, that's a really useful hook from @Robin S, which I've already made use of (but not for Form Builder fields).
  23. Yes, completely possible! Indeed, I'm not sure why you're losing the spaces. Do you have a text formatter (on the Details tab) applied to the field? If so, this might be removing the spaces. If the textarea uses a rich text editor (CKEditor, TinyMCE), it's possible that the editor (or an associated function) is removing the spaces, so it'd be worth checking the settings. I can't think of one that would do this off the top of my head, but I may well have forgotten something! If it's neither of these, take a look at the HTML in your browser using the Inspect option. And if that doesn't clarify whether spaces are getting through to the page, you could check using something like: echo str_replace(" ", "_", $page->myTextField); If underscores appear, the issue is something to do with the rendering of the page. You could try replacing the the underscores with &nbsp; in the above, though this shouldn't be necessary for the spaces to render in a <pre> element.
  24. By chance, I use the same two suppliers as @millipedia, and have been pleased with both!
  25. Welcome to the forums! I have three suggestions. First, when using PW, don't think about SQL unless you really, really have to – and it'll probably never be necessary! Second, when deciding how to structure data, it's usually best to start by thinking of each major item as a page, and move on to complex field types only if it would improve things (usually because it will help with human editing of data). So, for example, you might handle each booking as a page, and then use a Page Reference field to link to the relevant event. Third, if you haven't already, look in depth at selectors (very important and a great feature of PW!) for retrieving the data you need. Let us know if further help would be useful!
×
×
  • Create New...