Robin S

That sounds sensible. Thanks for the fix.

@szabesz, sreeb is concatenating not interpolating so either single or double quotes will work. @sreeb, you are using single quotes around the background URL path inside the single quotes of the style attribute: echo "<a href='".$block->url."' style='background: url('".$block->front_block_img->url."') no-repeat bottom center; background-size: cover;'>"; That effectively ends the style attribute prematurely. Either use escaped quotes around the background URL path... echo "<a href='".$block->url."' style='background: url(\"".$block->front_block_img->url."\") no-repeat bottom center; background-size: cover;'>"; ...or just leave out the quotes around the background URL - you only need those if there is a space in the path and that will never happen for a PW Pageimage as files are renamed on upload. echo "<a href='".$block->url."' style='background: url(".$block->front_block_img->url.") no-repeat bottom center; background-size: cover;'>";

GitHub issue opened: https://github.com/processwire/processwire-issues/issues/255 Apparently it's quite easy to unknowingly call the php-cgi binary from a cron job on cPanel servers because the paths changed starting in EasyApache 4 (previously the /usr/bin/php path pointed to php-cli).

After updating Tracy the notices are: [01-May-2017 20:30:02 Pacific/Auckland] PHP Notice: Undefined index: REQUEST_URI in /home/myaccount/public_html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/TracyDebugger.module on line 1583 [01-May-2017 20:30:02 Pacific/Auckland] PHP Notice: Undefined index: REQUEST_URI in /home/myaccount/public_html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/TracyDebugger.module on line 259

It's the same, just replace $page->custom_date_field with $page->created or $page->published

Hi @adrian, I have a PHP file that bootstraps PW and I'm calling it from a cron job. When the cron fires I get the following errors relating to Tracy: [01-May-2017 13:07:01 Pacific/Auckland] PHP Notice: Undefined index: REQUEST_URI in /home/myaccount/public_html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/TracyDebugger.module on line 1541 [01-May-2017 13:07:01 Pacific/Auckland] PHP Notice: Undefined index: REQUEST_URI in /home/myaccount/public_html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/TracyDebugger.module on line 233 I also get an error from ProcessWire.php that I've created a separate topic for - I just mention it here in case the issues are related.

I have a PHP file that bootstraps PW and I'm calling it from a cron job. When the cron fires the script does run but I also get the following error notice: [01-May-2017 13:07:01 Pacific/Auckland] PHP Notice: Undefined index: argc in /home/myaccount/public_html/wire/core/ProcessWire.php on line 260 I've seen this reply to a similar problem... ...but I'm not sure that applies in my case. My site is on a shared host and I get the error when I call my cron job like this... php -q /home/myaccount/public_html/tm_import.php ...which is the recommended format according to my host's documentation. I tried this... /usr/bin/php -q /home/myaccount/public_html/tm_import.php ...and I get the same notice. Whereas based on @BitPoet's suggestion when I try... /usr/bin/php-cli -q /home/myaccount/public_html/tm_import.php ...my script doesn't run. Incidentally, line 260 of ProcessWire.php checks if php_sapi_name() == 'cli' and in my case php_sapi_name() is 'cgi-fcgi'. So I'm wondering if PW should be checking for some other variants of php_sapi_name() and I should file a GitHub issue for this, or if I'm just doing something wrong in my cron job. PHP 7.0, PW 3.0.55

@Slav, another option is to set a redirect URL in the "Access" tab of the template that has restricted access. So if I user attempts to access a page with that template when they are not logged in (for any reason - either they logged out or their session expired) they are redirected to a page of your choosing.

Not 100% sure on this, but I think it will be because of the multi-instance support introduced in PW3. The example you gave from CommentFilterAkismet.module... $inputfields = $this->wire(new InputfieldWrapper()); ...if you check the PW2.x version of this file, before multi-instance support was added, it is simply... $inputfields = new InputfieldWrapper();

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.