Robin S

If you removed /site/config.php that will definitely cause a problem. No need to touch that file when upgrading.

This pretty much works - it just misses out the trailing slash from the original $compilerCachePath so results in a double slash in the link URL. But this could be corrected: $compilerCachePath = realpath($compilerCachePath) . DIRECTORY_SEPARATOR; Alternatively, slash replacement could be done conditional on what the directory separator is (thereby distinguishing Windows from Mac/Linux): if(DIRECTORY_SEPARATOR == '\\') $compilerCachePath = str_replace('/', '\\', $compilerCachePath); Or no conditional needed for this one: $compilerCachePath = str_replace('/', DIRECTORY_SEPARATOR, $compilerCachePath);

Oh right, of course. Yes, that would work. You're right. I'm just being lazy and leaving the file watcher at the default scope, which is all project files. But I could define a custom scope for each project, or use the preset "open files" scope and just be careful not to accidentally open AdminOnSteroids.scss

Thanks, that wouldn't help because the file would still be within the project scope (the whole PW installation is). Somehow AdminOnSteroids.scss would need to be excluded from the module files that are downloaded/installed from GitHub. I'm not very familiar with Git so not sure what options there are for that. Or a different file extension used? I guess that would foul up things at your end. Maybe it has to go into the too-hard basket. I actually only need the SCSS file watcher active while the site is at the static stage, so I probably just need to remember to turn it off afterwards.

@adrian - sorry for the delay. The change you suggested doesn't allow the file compiler path to be successfully replaced. For me the $compilerCachePath variable before the change is... D:/Websites/pw3-testing/site/assets/cache/FileCompiler/ ...and after the change it is... D:/Websites/pw3-testing/site/assets/cache/FileCompiler\ ...but to successfully replace the link to the editor it needs to be... D:\Websites\pw3-testing\site\assets\cache\FileCompiler\ I originally thought my str_replace suggestion was hacky but now I see there is already something similar in the nette/tracy source so maybe it is an okay way to deal with these path issues?

@tpr - Is AdminOnSteroids.scss a necessary part of the module, or is this file only used by yourself to generate AdminOnSteroids.css? Just wondering if it could be excluded from the GitHub repository - the issue I'm striking is the when developing locally PhpStorm's SCSS file watcher will automatically compile from AdminOnSteroids.scss and overwrite AdminOnSteroids.css, producing a different result. If it is a necessary part of the module that's fine - it's possible to avoid this at my end by defining a custom scope for the file watcher, just requires a bit more setup in each project.

Thanks, I see now what the module author was trying to do. The problem is the CSS targets the wrapping list item as well as the text input. For a basic fix you can just change the CSS file so it consists only of: li.InputfieldAssistedURL input[type="text"] { width:75%; } Or you could add some wrapping divs in the render method that would let you achieve more precise styling: public function ___render() { $field = new InputfieldURL(); $field->set('name', $this->attr('name')); $field->set('value', $this->attr('value')); $field->set('class', 'InputfieldAssistedURL'); $btn = $this->modules->get('InputfieldButton'); $btn->attr('id', $this->attr('name') . "_assistedurl_open"); $btn->attr('data-page-id', $this->page->id); $btn->class .= " InputfieldAssistedURLOpen"; $btn->icon = 'link'; $btn->value = ''; $out = '<div class="InputfieldAssistedUrlButton">' . $btn->render() . '</div>'; $out .= '<div class="InputfieldAssistedUrlText">' . $field->render() . '</div>'; return $out; } .InputfieldAssistedUrlButton { float:left; width:60px; } .InputfieldAssistedUrlText { margin-left:60px; padding-top:6px; }

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