horst

The most UAs, regarding your screenshot, are a Facebook Browsers: FB_IAB/FB4A So, you first should check why / which Facebook-Apps are polling your site, and if they properly send session-cookies with each following request, or if they open a new session with every poll.

Everything has to be something!

Simple string concatenation also may help: $selector = "parent={$myParentContainer}, template=atemplatesname"; $selector .= ", fieldnameOne=1"; if(--someConditionHere--) $selector .= ", fieldnameTwo!=selected"; ... $selector .= ", sort=afieldname, limit=10"; and this:

Sounds interesting. - To ping ryan about it, you better submit an issue or a PR on github.

Some people do this via HannaCodes or other, self created markup-modules added to the ckeditor boxes. Something like that: [[image=theimagename.jpg, crop=thecropname]] The above could be used by a custom markup module, if you have not installed HannaCode. Assumed you have only one image field on that templates/pages, you have to search for that image in the field and replace that marker with the img tag and src pointing to the crop. if you have more than one imagefield on a page, you need to add a third param: [[image=theimagename.jpg, crop=thecropname, fieldname=teaserimages]] If you are willing to get your hands dirty with code and build an own markup module, this is a nice way to learn much about PW and PHP. Otherwise you can install Hannacode and do it there. Hannacode is a flagship! Pretty usefull for a lot more use cases.

Only thing what comes to my mind is different user rights!? Can you somehow log user name / role for the different scenarios? (Maybe by temporarily add a log into the send function)

For the topic how to import / batchimport content into PW you will find many posts with examples in the forums, - so I will focus on your special issue with your images that are linked to "./images/...." in your htmlContent. Assumed, you use an importer script, that reads the following from a source: title / name of an entry html content images basenames Assumed, that the importer script can access the imagefiles / knows where they are kept for the import. And assumed that you have created a template with fields for those pages you want to create during the import. Then you will come to a point, where you programatically create a new page: $p = new Page($myTemplateObject); $p->of(false); $p->title = $theEntryTitle; $p->parent = $theParentContainerPage; $p->save(); Now you can add / import your images to an imagefield: foreach($imagebasenameArray as $basename) { $p->imagefield->add($directorypathToImages . $basename); } Now all images of that entry resides in /site/assets/files/{PAGE_ID}/. And you have to modify your html-content to match this: $p->body = str_replace("./images/", $config->urls->files . $p->id . "/", $htmlContent); $p->save(); This way you will have the most possible flexibility with your pages, I think. Please note: written in the browser, - may have bugs, - is meant as pseudo code.

Cool, Tested it mobile.

https://processwire.com/api/modules/api-explorer/ API Explorer, always uptodate with your used PW version. Its a ProModule. EDIT: Oh, @adrian was faster.

Reading the error, it says you have a type error. It expect an Object of type Page, but it got passed an object of type PageArray. So, it has nothing to do with your sort of include, I believe. So, somewhere in your (template ??) code you have called ukEventPost() and passed it a PageArray instead of a Page. Please refer to the other error lines until you found which file / line raised it, and change this, that it passes a single Page, and not a PageArray.

Sorry, AFAIK, GD doesn't support TIF.

Thanks Ryan. Very good progress on this! Can't wait to see what the communities front dev pros can show us how to use it / what all can be done with it, now that you have opened it for easy configuration.

not uploaded through the forums software, the @Real_Original_Images please. packed into a zip should work.

@chrizz your calculation is totally wrong. Only thing that is of interest for imagesizer is uncompressed image in memory. You do not hit a filesize limit, you hit a memory limit. Why you run into it, I can't say. But I can say that we do runtime checks for available memory before opening an image in memory, but also we use a fast calculation depending on most common images for that. Without seeing your original images, I guess your original image has some image markers like EXIF, IPTC, VENDOR-Tags etc. what may be a little over the top of what we use for our precalculation. Theoretically it is possible to pack a lot of data into this, but typically it isn't that big. Maybe an edgecase? (Calculation like we do, fits just into available runtime memory, but without the ImageMarkers?) But one thing is a physical fact: FilesizeCompression cannot reduce needed memory limit. (and therefor I do not need deep theory, this is simply how computers work since ever. In my earlier days, around 1994, we sometimes do some jokes: we compressed big dimensioned jpeg images with the lowest quality setting / highest compression rate, and send them as previews to Artdirectors with a question to them. Always when they tried to display it, it got loaded / uncompressed into memory and their systems imediately got freezed / unusable. So, we only have done that to very unfriendly people who really deserverd a little shock. ) So, what ever you have changed in your second saved imagefile, what is responsible for the fit into memory than, it is not filesize compression. A serious test would need to log the runtime available memory for both images before trying to open it, and the same after they allocated the memory, and compare all that. Also a full check of all file parts in the imagefile (markers and image data). Without that, it says null to nothing and only opens room for glasball looking, guessing or misinterpretions.

and the file of your MenuMaker is located and named like so: "site/modules/MenuMaker/MenuMaker.module" ?

I have read it. - Is a special but also very interesting solution. Thanks for sharing.

@PWaddict: just to clarify: There are two things here: The modules version is recognized and the module gets correctly updated via the individual update function in the modules config screen! The module is not recognized by the third party updater module. This is an issue of that updater module! What I have tried / described above, is to find a way / workaround without needing to contact the author of the third party module "updater" and ask him if he can debug and change the module to recognize modules that are organized like CI3 too. One way I found out to get recognized by the updater, is to use a wrapper module in the root directory of the module. This will work, AFTER everyone has updated to that version. But with the current situation, before everyone has updated to that version, there may be danger to break systems when silently changing the modules hirarchy and dependencies.

what issue? that it is not recognized by the upgrader? this is expected, as i haven't changed anythig than the version number from string "0.9.17" to number 100.

Uhm, thats sort of a Problem! I think I cannot simply update it this way, as it may break systems. There are also the check for updates right in the config screen of the module itself, what currently works well. Needs more testing before. It would be helpful to get some minds / thoughts about this from the veterans. manually update needs to copy all new files over the existing ones (optionally ?) flush the modules cash Install the new wrapper module I can push it to a test-branch for those who are reading this. But this is not of help for those who want / need updates via PW (individual in module config or via updater module) ??

No, this is not possible, because if the original update could be with different dimensions than the previous version. If so, there is big potential to crash the image manipulation script with crop settings out of bound of the new original image.

on a local test I added a fake module in the root of the modules directory hirarchy and changed the dependencies hirarchy to make it the main module that installs the three others: /site/modules/CroppableImage3/ /site/modules/CroppableImage3/CroppableImage3.module ** /site/modules/CroppableImage3/FieldtypeCroppableImage3/FieldtypeCroppableImage3.module /site/modules/CroppableImage3/InputfieldCroppableImage3/InputfieldCroppableImage3.module /site/modules/CroppableImage3/ProcessCroppableImage3/ProcessCroppableImage3.module ** @adrian: This way it get recognized by the upgrade module. It seems, it has nothing to do with the version is a number or a string.

normally, the version compare function (should) work correct with strings like "0.9.17". But I can temporary change it, if this would help. (?) I have updated the repo and changed the version from string '0.9.17' to number 100. Does that change anything?

On one server it is running after upgrading to 3.0.52, on another one not! This is not really a pattern, or is it one? @Macrura, can you give me access to that one where it is returning null? I use it on my installs and it works all as expected.

@Nurguly Ashyrov I really like what you do here! So much fun to see this. Unfortunately I have no time ATM to start playing / using it. (buhuhh, - schnüff)