Robin S

  • Content count

  • Joined

  • Last visited

  • Days Won


Robin S last won the day on April 15

Robin S had the most liked content!

Community Reputation

1,826 Excellent

1 Follower

About Robin S

  • Rank
    Hero Member

Profile Information

  • Gender
  • Location
    New Zealand
  1. I have a piece of expensive code/markupthat I am caching using WireCache. I have a Pages::save hook for pages of a particular template where I clear the cache to account for the changes. $this->cache->delete('my-cache-name'); In that hook, after the cache is cleared I want to regenerate the cache, so the expensive code is run then rather than when a page is viewed on the front-end. I thought that this would do that... $this->cache->preload(['my-cache-name']); ...but based on the execution time of the next page view on the front-end, which I'm tracking with Debug::timer(), it seems like the cache has not been regenerated in advance. Is this what $cache->preload() is for? i.e. regenerating a cache ahead of time so it is ready to go when called for. And is there some trick to using it that I'm missing?
  2. @Gideon So, there is indeed a $page->find() method: @xxxlogiatxxx, I've read your question a couple of times but I can't work out what you are trying to do. You populate a variable you have called $fields. Firstly, you should choose a different name for this variable because $fields is the name of an API variable: Secondly, you populate this variable from $page->find() and the result of this will be pages not fields. Can explain more about what your aim is?
  3. $selector= 'template='.$template.', limit=4, sort=random'; $subs = wire('pages')->find("$selector"); // $subs is a PageArray foreach ($subs->children as $tree_item) { // A PageArray can't have children, only a Page can have children
  4. Hi Teppo, As a superuser I find the Tree menu great, but I have some roles for whom edit access is quite limited - most pages in the site are not editable by them. For those roles I think the Tree menu is less useful and it can be confusing. If you click a page in the Tree menu that you do not have edit access for you are taken to view that page in the frontend. I think that is unexpected and not helpful to the user. At the time I made the module there was no way to visually distinguish between editable pages and non-editable pages, although I think Ryan plans to fix that soon (might be done in v3.0.60). Also, although the pages shown in the Tree menu are the same as those shown in the page list, my perception is that it makes some of the pages that site editors don't need to concern themselves with (e.g. the FormBuilder iframe page, the 404 page) more prominent than they are in the page list. I could see myself having to deal with support requests from clients confused about what they see when they click these pages. I didn't think the Tree menu was worth it for those roles so wanted to selectively remove it.
  5. At a quick glance, one thing you should look at is applying a limit to the selector in your search template. Search results like this could quickly become a problem, particularly if there was some kind of bot hitting the site:
  6. Welcome Brian, There is a pro module you might be interested in that is designed for tracking performance and identifying bottlenecks: Profiler Pro There's more info about it in the blog post that introduced it: And with purchase comes support from the man himself. Ryan says: Might be a fast way to resolve the problem.
  7. Sounds like you have a good handle on how the process will work, so no reason to worry I think. I've just done something very similar so I can attest that it's quite simple to do in PW. Regarding 1 & 2: most likely you will be querying an API endpoint that will return a JSON string to you. You'll probably find the WireHTTP class useful here - that's what I used. The getJSON() method will convert the JSON response into an associative array that contains all the data you requested. Tracy Debugger will be useful for exploring this array. Then you will use some part of the data as a unique identifier (you could use the title string but there's probably some kind of reference code that will be a better candidate) and based on whether you can find an existing page with that identifier you will either create a new page or update an existing page. Then it's simply a matter of matching items in the array to fields on your page and saving the page at the end. You can use a lazy cron function to automatically query the API endpoint every 24 hours. To delete pages that are no longer contained in the JSON response you can collect all of the unique identifiers in the response and then use a PW selector to get pages not matching any of those identifiers. Those pages you delete.
  8. Thanks for the documentation updates! The text/background contrast in the code blocks is a little low - could the background be lightened, or text colours darkened? Or maybe switch to a dark theme for the code blocks? Thanks.
  9. Adding to this: long as you are starting with the "blank" profile. If you have installed a profile that is based on Uikit such as the new blog profile then the frontend will use Uikit.
  10. @thetuningspoon, I just pushed another small change in v0.1.1 to remove any manual line breaks that a user might insert inside a textarea. Manual line breaks cannot be supported because they break the CKEditor tag widget.
  11. v0.1.0: this time hopefully...
  12. I had thought it would be nicer if the module decided automatically based on the length of the attribute value you give it, but now that you mention this I can see that my idea won't work very well when inserting a new tag, where the length will be zero until it is populated. So in v0.0.9 I have removed that breakpoint idea and now you can manually specify the textarea inputfield type for an attribute, e.g. myattribute__type=textarea
  13. If the image is in the HTML source as opposed to a CSS background image, then maybe it is not cropped to a square ratio?
  14. Will it though? That's true for $pages>find() selectors but I think for a repeater field the whole PageArray is loaded to memory regardless. Or is there another efficiency?
  15. @thetuningspoon, thanks, I couldn't reproduce the issue exactly as you're seeing it but I think I have found the source of the problem. For some reason I didn't anticipate using long strings of text for attribute values. So I've added support for that in v0.0.8 and now if the length of a value is greater than 50 characters a textarea is used in the dialog instead of a text input. The breakpoint at which a textarea is used is configurable in the module settings. Please let me know if this doesn't fix the issue for you.