Robin S

It looks like ProcessPageEdit does not use the addActionValue() method but builds the dropdown independently: https://github.com/processwire/processwire/blob/3fc9f69da75e1bc4a3f0842f12a57bd6a1b65099/wire/modules/Process/ProcessPageEdit/ProcessPageEdit.module#L454-L491 Doesn't seems like it would be easy to modify that - probably via JS would be the only way. Maybe you could open a GitHub request asking to make it easier to modify that dropdown menu.

I think this would do the job: $cloneable = $page->parent->addable($page); // boolean true/false Plus check that the user has the page-clone permission, as @arjen suggested.

Thanks @abdus, that gave me the clue to getting Tracy working in modals. Just uncheck the "Hide Debug Bar in Modals" options in the Tracy config.

Hi @adrian, just leaving this here now while I remember for when you are back. I'm not able to use Tracy inside a ProcessPageEdit hook when the page being edited is a PageTable page (i.e. in the modal window). In /site/ready.php (or /site/init.php)... $this->addHookBefore('ProcessPageEdit::execute', function($event) { bd('testing'); });

I like to use the Connect Page Fields module but there is also another approach using an SQL query on the table of the Page field. An example... ...based on a suggestion from Ryan.

Setup > Templates > [template name] > Access tab

For a slider UI check out the new Jquery Ion Rangeslider module: http://modules.processwire.com/modules/jquery-ion-range-slider/ Or the earlier Range Slider module: https://modules.processwire.com/modules/range-slider/

Hi @Steven Veerbeek and welcome to the PW forums I'm not clear on whether you are talking about the config page for a 'normal' module or the page created by a Process module. But I don't think either of these will achieve what you're aiming for. A module config cannot use an actual fieldtype such as a PageTable or a Repeater - with the module config you are only dealing with inputfields and that's not sufficient for a working PageTable. And while you might get a bit further with a Process module you would kind of be going against the grain of how a Process module normally works. Normally the page created by a Process module uses the 'admin' template and you don't want to be adding a PageTable field to that. So you would need to create and assign a custom template. But then you also need to be opening this page in ProcessPageEdit in order to use the PageTable field and that's not typical for Process modules. So I think you probably need to work within the 'install' method of your module to: Create a new template Create a new PageTable field (along with the template for the pages used in the field) Assign the PageTable field to the fieldgroup of the template Create a new page using the template This page would then serve as a kind of config page for your module. But then again there might be another totally different solution to the issue of how to define your image sizes without using a PageTable field. If I understand right you want a way to define a variable number of image size settings for your module. The simplest way to do that would be using a textarea field that follows some predefined formatting, e.g. one line per image size setting with width and height separated by some character such as a pipe. Then your module uses explode() to parse the settings. I also wanted a repeatable format for module config settings and thought the textarea approach was a bit limiting and error prone. You might like to take a look at the system I have used for repeatable settings in several of my modules. Not saying it's best practice or anything but it gets the job done: https://github.com/Toutouwai/ConnectPageFields/blob/ef9a03d08f0e724724f13ebdb8dfb35a4662ec26/ConnectPageFields.module#L191-L340 If you come up with a better approach to repeatable module config settings be sure to share it!

You can revoke the "page-move" permission for a template per role:

A write-up/tutorial would be much appreciated when you're ready!

Nice site. @rick mentioned the slow loading of some images. The one on this page especially so: https://www.cds-service.com/en/solutions/remarketing/ It's 1.5MB!

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); }