Robin S

In PW3 all the core PW classes (e.g. Page, PageArray, or in your current case HookEvent) are in the ProcessWire namespace. So where in PW2 you can write the type hinting as... function menu_post_process(HookEvent $event) ...in PW3 you need the ProcessWire namespace, like this... function menu_post_process(ProcessWire\HookEvent $event) But rather than use the namespace every time you create a new instance of a class you can just declare it once at the top of the PHP file. namespace ProcessWire; And the idea of the file compiler is that you don't even need to do this - the file compiler takes care of it for you. But there are some files that the file compiler does not process. As LostKobrakai said in the other thread you linked to: And it sounds like in your case you have deliberately disabled the file compiler in certain files with: # FileCompiler=0 So therefore you need to manually insert the namespace declaration yourself wherever you instantiate a PW class.

It's a namespace issue. The file where function menu_post_process() is defined is not being processed by the file compiler, maybe because it is in an include. So add... namespace ProcessWire; ...at the top of that PHP file.

Your textarea tag isn't valid. Instead of... <input type='textarea' id='comment' name='comment'> ...it should be... <textarea id='comment' name='comment'></textarea>

If you set an array to openPageIDs then it must be an array of page IDs as strings. For example: $this->wire('config')->js('ProcessPageList', array( 'openPageIDs' => array('1045','1046'), )); If you would like the convenience of passing multiple page IDs as a GET parameter you could do this in /site/ready.php: $this->addHookBefore('ProcessPageList::execute', function($event) { $branches = $this->sanitizer->intArray(json_decode($this->input->get->branches)); if(count($branches)) { $this->wire('config')->js('ProcessPageList', array( 'openPageIDs' => array_map('strval', $branches) )); } }); Then you would link to the page tree like this: /processwire/page/?branches=[1045,1046]

This is because the module extends Fieldtype Textarea but removes certain config inputfields (including contentType) that are not to be used with Fieldtype YAML. I'm guessing that the core Fieldtype Textarea has added an inputfield dependency for contentType since the Fieldtype YAML module was created, hence the warning. @owzim, maybe the module could set the unused config inputfields to hidden rather than not including them in the field config at all? foreach($parentInputfields as $inputfield) { if(in_array($inputfield->name, $forbidden)) { $inputfield->collapsed = Inputfield::collapsedHidden; } $inputfields->append($inputfield); }

To get a page's children... $skyscrapers = $page->children();

Is this on a shared host? If so maybe mod_security got installed without warning and is giving a false alarm.

Yes. More info here: Rather than try and render the user template you can create a separate template for the profile page and... Get individual fields with $user->some_field Get all fields with $user->getInputfields() Get an array of named fields with $user->getInputfields(['some_field', 'another_field', 'field_the_third'])

@Amr Magdy, see Soma's solution here:

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.