horst

Have you cleared all sort of caches after you played in the dump?

Hi, welcome to PW forums. Looks like you have not the right PHP syntax. Try this: public function init() { // you need a condition that will result to true if($this->page->template->name == 'templateName') { $this->addHookAfter('save', $this, 'example1'); } }

in another thread I had posted some useful links to this too: https://processwire.com/talk/topic/15886-different-styles-for-results-of-an-array-page-grid/#comment-141785

I can second what @MuchDev said, but want to add that, for me, the cache field is/was yesterday. Today I only use the Textareas and Repeater Matrix from ProFields I try to keep the amount of fields as less as possible. Results in quick fulltext search without the need of a cache field, what would double the content size in DB. Really worth to use. Saves time too.

It is not when the property has empty values, it is when there isn't a key available. Your request return multidimensional array. If there is, for what ever reason, not set a key 'Make' or 'Model' for example, PHP will throw a notice when you simply try to use $myArray['availableKey']['notAvailableKey']. So, if you are 100% sure that all images that you ever will use with that code will have all requested EXIF-fields, let out the validation.

@Cengiz Deniz Yep, it works very well, but only until you request a key that is not available in an image, than it will throw notices or warnings. The new module I linked to, lets you do the exact same as you does, but without the redundant hassle of validation. So, you can use your code, but I suggest to add a check for available keys: $image="http://cdeniz.com/".$img->url; $exif = exif_read_data($image, NULL, true, true); $tarih = isset($exif["EXIF"]["DateTimeOriginal"]) ? $exif["EXIF"]["DateTimeOriginal"] : 'N/A'; // or anything you want, like '', null, ... $kamera= (isset($exif["IFD0"]["Make"]) ? $exif["IFD0"]["Make"] : '') . " " . (isset($exif["IFD0"]["Model"]) ? $exif["IFD0"]["Model"] : ''); ... ... ... Personally I find this to unreadable and redundant, therefore I prefer the new modules way: $options = array('keys' => array('DateTimeOriginal', 'Make', 'Model'), 'toObject' => true); $exif = $image->getExif($options); // now I can access like this: $tarih = $exif->DateTimeOriginal; $kamera = $exif->Make . ' ' . $exif->Model;

There is another module here: It has more configurable methods to get out what you want.

Very interesting, that CSS-Grid stuff. I'm thrilled. Here is a short list of usefull links: (must read) http://jensimmons.com/post/feb-27-2017/learn-css-grid http://gridbyexample.com/examples/ (some specs and technical info) http://gridbyexample.com/browsers/ https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout/CSS_Grid_and_Progressive_Enhancement https://drafts.csswg.org/css-grid/#grid-containers (some more) https://css-tricks.com/css-grid-one-layout-multiple-ways/ PS: you also can support older browsers with different fallbacks, there are tuts over that too.

Using filebased sessions is slower, and for every DB record, you will get a file in filesystem. This would be fighting the symptoms and not the reason! To be honest, a monitoring service that sends 7-15 requests in one second, each starting a new session is not what I would expect from professionals. At next step, I would drop that service and see how it comes with the total amount. Or maybe there are config options with that service? One request every five minutes would be enough, maybe?

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" ?