Robin S

Hi @Alxndre', I've been away for a bit so just following up now. Yes, the module works with both API and admin changes. In your code example you need to set the output formatting of $card to false before attempting to set values to a field.

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?

@Gideon So, there is indeed a $page->find() method: https://processwire.com/api/ref/page/find/ @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: https://processwire.com/api/ref/fields/ 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?

$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

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.

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: http://drydenwire.com/search/?query=a

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: https://processwire.com/blog/posts/a-look-at-the-new-profilerpro-module/ And with purchase comes support from the man himself. Ryan says: Might be a fast way to resolve the problem.

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.

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.

Adding to this: ...so 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.

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

v0.1.0: this time hopefully...

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

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?

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?

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

That's a bug, sorry. I missed something in the JS in a recent update. Should be fixed now in v0.0.7. Yes, the module should work for existing Hanna codes. I can't reproduce that issue here. If the v0.0.7 update doesn't fix things for you could you give me some more info: any JS console errors, the PW version, TextformatterHannaCode version, and an export of a Hanna code that you see the issue with? Edit: also please let me know how the Hanna tag looks in your CKEditor field - i.e. are the attribute values inside quotes, single or double?

@alan, besides BatchChildEditor another handy module for this purpose is ImportPagesCSV. You select a template and parent, then in "Paste in CSV data" you just paste in a list of page titles and put 'title' on the first row (to indicate it is a list of titles).

I think there is some confusion because the word 'tree' has in the past sometimes been used to refer to the page list (ProcessPageList) but now labels the dropdown 'Tree' menus. To be clear, the intention behind my module is not about preventing roles from accessing the page list, it's about removing the dropdown menus which I consider to be a confusing UI for roles with limited editing access. There is a related GitHub issue open here: https://github.com/processwire/processwire-issues/issues/231

Well it wasn't something I tested for specifically, but it was pretty easy to add support for ProFields Textareas so I have done that in v0.0.6.

@Ibrahim El Haddad, maybe you have a rule in .htaccess that redirects to the www subdomain? Either the one in the default PW .htaccess... # ----------------------------------------------------------------------------------------------- # 13. OPTIONAL: Redirect users to the 'www.' version of the site (uncomment to enable). # For example: http://processwire.com/ would be redirected to http://www.processwire.com/ # ----------------------------------------------------------------------------------------------- # RewriteCond %{HTTP_HOST} !^www\. [NC] # RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301] ...or some custom rule.

If you force the session variable to 1 whenever the templates list is viewed then it makes the "Show systems templates?" filter toggle non-functional. But I suppose you could take the view that if that AOS option is selected then you never want to hide the system templates, even temporarily.

Yes, PW uses a session cookie, and that's how session cookies work: https://en.wikipedia.org/wiki/HTTP_cookie#Session_cookie You can use the LoginPersist module to stay logged in across browser sessions.

I also dislike editing code outside of my IDE. The workaround currently is pretty simple - just set this for all your PHP Hanna codes: include($config->paths->templates . 'hannas/' . $hanna->name . '.php'); But I'm in favour of anything that would make it even easier.

Not sure I understand fully, but wouldn't that be reinventing the wheel? Hanna Code already does a great job of allowing the result of any custom code/function to be inserted into a textarea. Do you mean so you could have certain tags that are available only on certain pages? Because that is what the getDropdownTags() hook allows for: