Robin S

I see. The fix for that is nice and easy - remove this: https://github.com/marcostoll/processwire-fieldtype-assisted-url/blob/master/InputfieldAssistedURL.css#L6

I believe the code you're showing there comes from the render() method of InputfieldAssistedURL.module If you want to modify the module directly you would need to add a construct() method to set the prependMarkup and appendMarkup properties. public function __construct() { parent::__construct(); $this->prependMarkup = '<div class="InputfieldAssistedURLWrapper">'; $this->appendMarkup = '</div>'; } But probably better not to modify the module and rather set your custom properties in a hook. In /site/ready.php: $this->addHookBefore('InputfieldAssistedURL::render', function($event) { $inputfield = $event->object; $inputfield->prependMarkup = '<div class="InputfieldAssistedURLWrapper">'; $inputfield->appendMarkup = '</div>'; });

The methods for setting new options for an Options field via the API seem to be a bit convoluted - I think it's probably an oversight and it would be worth raising a feature request at GitHub. There's a method that seems to be primarily intended for the admin back-end: setOptionsString(). You can use it but the way the options are defined (string with line break separator) is a bit weird for API use and it's not easy to get it to play nicely with existing options. $f = $fields->my_options_field; $manager = new SelectableOptionManager(); $options = 'red green blue'; // you can also set IDs and values if needed $manager->setOptionsString($f, $options, false); // if last argument is omitted/true you will remove any existing options Otherwise you could manually create SelectableOption objects, add them to a SelectableOptionArray, and use addOptions(), deleteOptions(), setOptions(), etc, with that SelectableOptionArray. See the module source code. It's hardly a simple process though. I think what's needed are methods to go from options to PHP array and PHP array to options.

It's in the modules directory here: http://modules.processwire.com/modules/fieldtype-assisted-url/

It works for me - what part isn't working for you? $result = $page->getUnformatted('my_pagetable_field')->first(); echo $result->my_image_field->first()->url;

@szabesz - I had a play around to see how you could use custom PHP replacements in the description field. My first thought was create a module where you define tag/code pairs in the module config, then look for and replace those in descriptions. This works, but requires the use of eval() and conventional wisdom is that eval() is evil. So my next thought was Hanna Code, and this seems to work great. In ready.php (or create an autoload module): $this->addHookBefore('Inputfield::render', function($event) { if(!$this->wire('modules')->isInstalled('TextformatterHannaCode')) return; if(!($this->wire('process') && $this->wire('process')->className() == 'ProcessPageEdit')) return; $inputfield = $event->object; $description = $inputfield->description; if($description == '') return; $this->wire('modules')->TextformatterHannaCode->formatValue(new Page(), new Field(), $description); $inputfield->description = $description; }); Then set up the Hanna codes you want to use in description fields. If you want to get the page object for the page being edited then add this at the top of your Hanna code... if($process && $process->className() == 'ProcessPageEdit') { $p = $process->getPage(); } else { return "[Hanna code '$hanna->name' is not valid for this field]"; } return $p->url; // an example to return the URL to the page without scheme and hostname ...then access the page object as $p

A PageTable field will not normally output a hidden page either. See here. But you can use getUnformatted() to get unpublished or hidden pages. $result = $page->getUnformatted('my_pagetable_field')[0]; //or $result = $page->getUnformatted('my_pagetable_field')->first();

For me, all internal links made in a CKEditor field are relative links, and these wouldn't need to be updated if the site was moved to a subdirectory. Not sure why you would be getting absolute links in yours. There is a config setting for ProcessPageEditLink to set the URL type: Strangely, mine is set to "Absolute", but maybe this means "absolute relative to the site root"?

Is your CKEditor inputfield set to less than 100% width? Or in a fieldset that is less than 100% width? If so the culprit is probably the height spacer JS. GitHub issue here, has never been completely fixed. Only solution for me is never set CKEditor field at less than 100% width.

Thanks for the reply; no hurry at all. Am currently getting by using PageTable for page-per-image images, and when I get time I will explore Inputfield Selectize also as that looks like it would be good for the task. One last question for now: do you offer an upgrade path for your commercial modules? That is, if I purchase a Single license and find that I love it and want to use it on all my projects can I pay an upgrade fee to move to a Developer license?

I suggest using phpinfo to compare settings between the old and new server.

I am pretty happy with this solution - works for me anyways! Myself, I add SmartyPants and HTML Entity Encoder textformatters to all text fields.

I understand the thinking here, but agree with @adrian that often you want a single line input rather than multi-line. I know you want to avoid an overly-complicated interface but perhaps there could a "Rows" input for additional fields like for the Description field?

Are you running the same PHP version on the new server? Any differences in PHP settings? post_max_size and upload_max_filesize would be ones to check in particular. Another thing to do is open your browser JS console and look for errors during file upload. If there's anything there you can search the forums for references to the error. This post from Ryan has some good advice, and the whole thread discusses a similar issue.

Hi @adrian, I have had a look at this and I think the problem is due to the direction of file path slashes on Windows versus Unix. You can see mixed forward and backslashes in this screenshot of the Template Resources panel. It looks wrong but the links to the editor still work okay. Edit: apparently it's no big deal to mix forward and backslashes within a path for Windows. In terms of the error notice links containing paths to the file compiler cache, this is because having the slashes around the wrong way prevents the str_replace in Helpers::editorMapping from replacing the necessary section of the path. I got the links to work by adding the following after line 303 in TracyDebugger.module $compilerCachePath = str_replace('/', '\\', $compilerCachePath); Of course this is not a real solution. But maybe there is some cross-platform way to deal with file paths?

Sussed it after finding your discussion with Ryan in the Form Builder subforum. $this->addHookAfter('ProcessFormBuilder::getInputfieldPageClasses', function($e) { $classes = $e->return; $classes[] = 'InputfieldPageDependentSelect'; $e->return = $classes; }); Would be good to include this in the readme seeing as it mentions that the inputfield is a good addition to Form Builder. Or the hook could be done in a dependent autoload module that comes included with InputfieldPageDependentSelect? Thanks for making this cool module!

@LostKobrakai I'd like to try your InputfieldPageDependentSelect module in Form Builder but I can't work out how to get the inputfield to show up. I can use it for Page fields in the PW admin, but I can't select it for Page fields in Form Builder. Normal page field: OK Form Builder page field: missing It's also not available for selection in the Form Builder module config field: "Inputfield types to use with Form Builder". Can you see where I'm going wrong? Thanks. PW v2.7.2, Form Builder v0.3.0

That looks a bit strange to me. You are saying data is an array where the first value is the string 'notices' and the second value is the WireArray $notices - is that intentional? Or do you maybe mean: $data = array('notices' => $notices);

I've only just now noticed you are referring to the "Sort settings for children" on the template, not the page. I have never tried that setting before and always define sort settings on the page. I tested it in v3.0.35 and it seems that although you don't get the modal warning when changing the child sort order by dragging in the page tree, when you refresh the page the sort order is reverted to that specified in "Sort settings for children". Can you check to confirm? If the lack of modal warning is a concern (it does seem inconsistent with the behaviour from the equivalent sort setting on page) you could raise an issue on Github.

It works perfectly, thanks!

Just guesses here... Perhaps you should empty all caches before making your profile backup. ClearCacheAdmin would be useful for that. If you FTP to the problem directory, do you see anything there that might be preventing the creation of the temp directory? For example, an existing directory of the same name. You could also try a more traditional migration (i.e. zip/ftp/extract files, export/import db via phpMyAdmin).

Works for me. I put x-ray into the body field on page 'Three' and got this result in Selector Test: Edit: just realised you're asking about selector values that are going through a sanitizer. Not sure which sanitizer you are using, but $sanitizer->text() keeps dashes intact.

I solved this with a hook to Fieldtype::markupValue... $this->addHookBefore('Fieldtype::markupValue', function($event) { $f = $event->arguments('field'); $p = $event->arguments('page'); $v = $event->arguments('value'); if($f->name == 'my_field' && $p->template->name == 'my_pt_template') { $event->arguments('value', $this->sanitizer->text($v)); } })

I have a field that has the Parsedown textformatter applied, and I want to include it as a column in my PageTable field. But entities are encoded (for security?) so the HTML tags are rendered literally: This doesn't look good - even stripping the tags would be better. Is there a way I can avoid the literal tags?

Your link to the topic you followed doesn't work, and I'm not sure what's in your renderPosts() function, but assuming that LostKobrakai is right and you are using $page->render() (edit: I see the render() call now), another alternative is to place this at the top of the template you render: if( empty($options['pageStack']) ) throw new Wire404Exception();