Jump to content

BillH

Members
  • Posts

    256
  • Joined

  • Last visited

  • Days Won

    4

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

     

     

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

     

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

     

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

  6. 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')
  7. 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).

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

    • Like 1
×
×
  • Create New...