adrian

Just a guess, but what about the path to your query.php. You say it's in your website root, but if it's being called from a PW page, then you need to use a root relative path, likely just: url: "/query.php", Don't forget that you can find out if there was a 404 on that file in the Network tab of your dev tools console.

There are lots of options, but the two I like are: Using the template conditional options in AIOM: http://modules.processwire.com/modules/all-in-one-minify/#conditional-loading Or otherwise you can add the js script call in a variable in your template, eg: $end_head = '<script src="myscripts.js"></script>'; Then in your main.inc or whatever file is your master template, just echo out $end_head before the closing </head>. Of course you could also do this with $end_body if more appropriate for your script file.

PR has been submitted to fix those fatal errors in PHP 5.3. The other relatively minor (but niggly) thing is that the description field is not getting the InputfieldMaxWidth class applied to it and as a result, the input is very narrow. I took a quick look at the regex stuff you have going on in regard to this, but figured it was easier for you to figure out the issue with this because I haven't really figured out why you are replacing the label class and label for description, although I am sure there is good reason

Hi Ryan! Sorry for pestering, but now that 2.5.20 is out, I wanted to reiterate my concern around the min size issue - this really is a deal breaker at the moment. For example, if you plan to display a headshot of someone at 150px x 150px and you set the Min Image Dimensions accordingly, but then they crop or resize it using the new functionality, you will end up with a very pixilated image, or one that is too small (if upscaling is disabled) if your template call is $image->size(150,150)->url and they have made it significantly smaller. I also agree that renobird's idea would be a useful additional option, but based on your comments about the core functionality vs CroppableImage, I think you might think that is something beyond the scope of the core? The other critical thing in my mind is the ability to disable "Save as Copy" on a field by field basis - in addition to my thoughts above, this will also be a big problem for image fields that are used for populating galleries, carousels, etc - you can't rely on editors to not use this option and it will currently result more than one version of the same image being output. Thanks!

Sorry for the confusion - I was looking at the wrong server. The server in question is running 5.3.29 so it's simply an issue with using $this in the anonymous functions (not allowed in 5.3) you are using, so should be an easy fix.

Yep, I checked add internal link field box. The image uploads fine, and i can add a link, but it doesn't matter whether I actually add the link or not, I still get that error and the only way to get it to go away is to remove the field from the template, or uncheck internal link field box for the field. It seems to occur with every page containing the field. The only thing I can think of that might be making it work on one server vs the other is php version: 5.6.4 works, but 5.4.33 5.3.29 doesn't.

Why do you need to use a fake page? Why not use an existing one - could be any existing page, or one dedicated for the purpose. $img = $modules->get('InputfieldImage'); does work if you use $img->attr("value", new Pageimages($this->page)); It would be helpful to see all your code - how are you using WireUpload? I know you say it works, but I think ->destinationPath should be ->setDestinationPath - at least that is how I have always used it. On that note, I put that as part of the image upload processing, not the upload input field, eg: // save image to page //WireUpload stuff $validExts = array('jpg', 'jpeg'); $imageProcess = new WireUpload("ImageUploadJPEG");//name of image file upload <input> $imageProcess->setOverwrite(true);//overwrite files $imageProcess->setMaxFiles(1);//only allow one file! $imageProcess->setDestinationPath('/temppath/'); $imageProcess->setValidExtensions($validExts);//check for valid file extensions //upload the image file $arr_file = $imageProcess->execute(); Does any of that help?

On one of my PW sites it works fine, but on another one, if I try to edit a page with an image, I get this error: Error: Using $this when not in object context (line 213 of /home/path/site/modules/ImageExtra/ImageExtra.module) Both site are using the same versions of Image Extra and PW (both the very latest).

Hey Ryan, I see that you just implemented a fix for the Max 1 and the Save as Copy, and also the modal size - thanks! One more thought for you - do you think that the cropped image should respect the "Min Image Dimensions" settings. I think it is strange to allow someone to resize or crop an image to be smaller than this setting's value.

Looks like chrizz has disappeared from this topic - we PM'd a bit about it and I implemented a fix for his problem, but never heard back. All that is needed is to add the following: // make sure the value is of type Pageimages $obj_field->attr("value", new Pageimages($this->page)); You can thank soma for that fix: https://github.com/somatonic/ImagesManager/blob/master/ImagesManager.module#L173 Does that take care of your issues too?

Not referring to adding of new pages - I understand how it works in both modules - I am talking about the way they display existing pages - ChosenSelect loads all into the DOM using the Select field. Autocomplete uses ajax to search and return matches dynamically.

Autocomplete is actually really nice. I see pros and cons compared with ChosenSelect and I think it comes down to how many tags you are likely to end up with. Automcomplete uses ajax to load matching pages/tags, but this means that you can't browse existing ones like you can with ChosenSelect, but maybe nicer than potentially loading up hundreds of items into the DOM. Sorry, will stop the OT comments now

The problem is more of a user interface one, than a coding issue. If you have grandchildren that are editable, but children (their parent) that is editable, then you have to show that level anyway, or the page tree would become a mess Have you tried this: https://processwire.com/talk/topic/1176-hiding-uneditable-pages-from-users/?p=84916 That way you can hide the branches you want from the appropriate roles. Alternatively, have you considered a custom admin page - either a process module, or one of these modules: http://modules.proce...cess-dashboard/ http://modules.proce...n-custom-pages/

Hi Qurus and welcome to PW! It really depends on your needs. Do you need to get all images from all children of a certain page, or just one image from one specific child page that you can target directly? Basically you need to select the page somehow: For example this will get the url of the first image from a field called "images" from the first child of the current page: $page->child->images->first()->url If you need further help, let us know exactly your setup and we can help further.

Not sure if this is a new bug or not - I haven't seen it on other sites, but I just installed it on a new site and with HTML minify turned on, certain spaces are being removed. This works as expected: <strong>Lesson Rating: </strong>Excellent But if the code is generated like this, the space between ":" and "Excellent" is removed: <strong>Lesson Rating:</strong> Excellent

Hey Ryan, I have just started looking at the new cropping functionality - it's awesome, but I have a few thoughts I wonder if rather than the onhover edit button, it would be better to have an obvious edit/crop button - at the moment, I think editors will need instructions on how to find it. I'd also like to see the crop, resize, min, and max button permanent, rather than onhover for the same reason - they are going to open the modal and stare at it, not knowing what to do When the image is cropped very small, the resize, crop, max, min onhover buttons get messed up as there is no room for them to display - my comment above would solve this. Speaking of those onhover buttons - do these work ok on touch screens? Again #2 would solve this if they don't work well. There seems to be a random bug with the modal edit window sometimes being much taller than the viewport, so after I click "Save Crop", I have to scroll down a LONG way to get to the "Save as Copy", "Save and Replace" and "Cancel" buttons. This is on the default admin theme and it's not all the time. I am honestly a little confused by the "Save Crop" button - I have to save it, then choose one of the other three options. It is a different behavior to the resize options where I am asked to use existing or original. When the images field is set to Max = 1, Save as Copy is a little confusing as initially both appear once the modal is closed, but after page save, the original is gone. I would like to see a way to disable the options and force replacement of the original - I think this is likely the most common scenario. Especially if the image is not being embedded into an RTE, I think the current behavior makes it difficult to use the API to target the one cropped version of each image if there is no Max set for the field - you could end up with multiple copies of each image and no way to figure out which one the editor actually wants to use on the page. Thanks again for all these new tools!

What you are looking for is a Process module. There are lots of examples that you can use as a starting point - any module that adds a page under your Setup menu would be a good place to start. Other alternatives that you might find helpful include: http://modules.processwire.com/modules/process-dashboard/ http://modules.processwire.com/modules/process-admin-custom-pages/

You might also find this useful: echo $fieldtypes->implode('<br />', 'name'); It will list out the names of all installed fieldtypes, both core and those from site modules that you have installed.

I have been using https://dlvr.it/ for quite some time, but there are lots of solutions out there if you google "rss to facebook"

Have a read of this thread about the main PageTable field: https://processwire.com/talk/topic/8177-page-table-howto/ It is possible to automatically add existing pages if they are under the same parent. If they aren't then you can add them with a small bit of API code which Macrura shows in that thread. Hope that helps!

As noted above by Pete (2nd post), what you are actually looking for now is: throw new Wire404Exception(); Does that work for you, or is there something else going on still?

You could definitely do this so long as you have exec available for PHP and also have imagemagick compiled with ghostscript. If these requirements are met, then something like this should work: exec('convert -density 600 document.pdf[0] -colorspace RGB -resample 300 output.png'); inside the thumbnails function: https://github.com/uiii/ProcessWire-FieldtypePDF/blob/master/PagePDF.php#L7

Just had one more thought for you - how hard do you think it would be to also offer this as an inputfield for Ryan's new Options fieldtype, in addition to the Pages fieldtype that is currently uses. Thought it might be nice because with tags it is often unlikely that you actually need these to be accessible via a URL, hence no real need for having them as pages now that we have this new fieldtype. Just thinking out loud if you are looking for something to do

Awesome - so much better with Enter working to add tags - thank you! As for the no results/placeholder text - I might just go with some jquery. Thanks again for a fantastic job on this - it really is the best solution for tags fields!

Sounds great Pete - please revisit this if you get the time. Like lots of us, I have been using PageTableExtended for this sort of thing, but I would love to see a fieldtype like this - would make it much easier to set up and be better for selector driven searches, and would generally feel cleaner - at least to me!