teppo

@Fokke: yeah, sure did -- and Toto was totally amazing. Only had time to see their gig, though. Person sitting next to me was quite literally sleeping (at least that's what it seemed like) and after they had stopped drumming someone commented that it was like "the Orient Express departing." Unique experience to say the least

Thanks Ryan! I've just pushed to GitHub a new version with your fixes (and another minor layout fix for long revision lists.)

That "$page->child->children->children" is the issue here; $page->child is a Page, $page->child->children is a PageArray and you can't ask for children of a PageArray. PageArray contains Pages, each of which has children -- PageArray itself doesn't have children. You'll have to iterate over all contained pages one by one and ask for their children <?php foreach ($page->child->children as $children) { foreach ($children->children as $child) { echo "<h1>{$child->url}</h1>"; } } ?> Does this make sense to you?

@Macrura: I'm planning to port this for TinyMCE at some point, though personally I no longer use TinyMCE anywhere, so this hasn't really been too high on my todo list CKEditor loading blank sounds like an issue with ACF so I'd try disabling it and see if it helps; usually you can find your way around it's quirks, but having had more than my share of trouble with it I'm no longer sure if it's actually worth it. That's a typical issue for something like not having "div" in available format tags list while having div tags in your content. Note: having these tags in extraAllowedContent doesn't seem to make any difference at all. .. and, honestly speaking, CKEditor is awful when it comes to error messages and exception handling. Usually it just disables all or some features seemingly without any logical reason. Just guessing, but they probably thought that showing nothing would be better than showing incomprehensible technical error messages -- or something like that

I really like the site, looks and works great both on desktop and mobile. It's awesome to see more Finnish ProcessWire sites too (Planning to visit the event opening night today, by the way.) @adrian: interesting point about "English" vs. "In English" -- latter is pretty much the de facto standard way for linking to English language version around here

Just for the record: I'll consider using a captcha, blacklist etc. once honeypots (regular or reverse) start failing me. So far they've provided better results than any other solution -- and all that without breaking UX.

Hello there, and welcome to the forum! To answer your last question: yes, it should work. This seems like a strange one, I can't seem to spot the issue right away. It kind of sounds like there was a case where job_image->first() returned nothing (or, at least, something other than an object). Is there a single call to that function in this page and you're sure that the target page has an image? You're not by any chance iterating over multiple pages and outputting their content? It'd be helpful to know what exactly is returned: $firstimage = $finalarrayitem->job_image->first(); // get the type of returned value echo gettype($firstimage); // if it's an object, see if it's a Pageimage if (is_object($firstimage)) echo " " . get_class($firstimage); Of course you could also try doing var_dump($firstimage), but for larger objects that's somewhat difficult to read

@NooseLadder: this module makes it easy for users to embed maps within content generated with RTE -- TinyMCE, CKEditor etc. Use cases are very different. Just for the record, aforementioned editors do provide a way to edit markup directly, so technically it would also be possible to embed iframes etc. this way. That's something we don't usually want users to do because it often causes more problems than solves. It's better to provide simple solution that outputs consistent markup instead of giving end users too much freedom to do (and break) whatever they want. Added bonus (when compared to embedding iframes directly) is that if you (or Google) ever decide to change how maps should be embedded, you'll only need to change the code once (in the module) instead of changing it everywhere it's been embedded

@Pete: this is a bit old, but Ryan has explained it here. In that reply he also says that he'll add support for multidimensional arrays soon.. but as far as I can see, it's still expressly disallowed: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/Input.php#L62. So.. good question

Good point, actually. My answer was (at least) partially wrong / lacking It seems that this security behavior (blocking access from JavaScript to clipboard) isn't (anymore?) tied to iframes. The fact remains that in order to achieve this, you'll have to disable the CKEditor context menu. There's some discussion about this at StackOverflow here: http://stackoverflow.com/questions/2246631/how-to-disable-ckeditor-context-menu. This might cause some issues, though; one reply there claims that you'll also have to disable tabletools plugin. I'm not entirely sure of the scope of that plugin, but I'm afraid that disabling it might make it impossible to add tables -- or at least edit them once they've been added.. which is kind of problematic. (In this forum tables are disabled altogether, so this isn't an issue here.) Anyway, you might try those tips if pasting with mouse / right click feels important enough

@Joe: not possible. See http://ckeditor.com/forums/Support/How-copy-and-paste-normally for details. It's a browser security feature that prevents JavaScript from accessing clipboard within iframes. Editor used on this forum doesn't create a context menu of it's own like CKEditor, thus it's not affected by this.

@Macrura: I've just pushed new version to GitHub with "version-control" permission. This is going to be installed automatically with the module, but if you've already installed and don't want to lose any data, simply add a new permission called "version-control" manually and apply it to appropriate roles.

Agreed, this is a problem for anyone using CKEditor together with Hanna Code. Entities config setting seems like a good solution, at least I'm not aware of any serious drawbacks to that. There's another option (config.basicEntities) for things like <, > etc. which could be potentially harmful if left unescaped. We're talking about HTML markup here, after all. If I ever needed to use comparison operators as parts of Hanna Code variables, I'd probably let CKEditor escape them and then handle decoding in the code snippet with str_replace() or html_entity_decode(). If you're wondering what these config settings can cause, I'd suggest taking a look at CKEditor source. There you can see a list of all entities separated to couple of different variables; htmlbase is only affected by config.basicEntities while encoding all the others (entities, latin, and greek) is going to be disabled if you set config.entities to false.

@visualcookie: did you insert those paths in that format exactly? As far as I know, you should insert them starting from /site/ (ie. /site/templates/_sitejs/.) Probably something you've already tried, but just making sure