Soma

@Ryan, love the new features. Regarding inserting images in a RTE, is this something you guys still do? How do you handle it so clients don't mess up? I don't see how that is convenient? I mean if we allow clients to insert images in the Text, shortly after there's a complete mess of images to clean up. So I'm not sure what to think of the new image features being focused on this? What we love to see is a image manipulation tool to cut an original image, to then create thumbnails from. Croppable image does a good job, but still missing a cut the original image feature.

But then you already got the page ($p) so why get it again?

It's "$pages->get($p->id)"

Yeah flexbox would make it a lot easier.

I don't think this will be easy It's because it's simple with its modularity and just a floating, but the other one would be errrhm...

It can be used, just what do you do if you have files in there that come from core modules you don't want? When using form API on front-end and load a Datetime field, css and js from that Inputfield will get added to the array, but I don't like to use backend scripts in the front-end. You add another dependency, that if core changes or has a bug you also have that on front-end after update. You have already have to take care of changed to Inputfields anyway so maybe it's no big deal. Also has cases where third party autoload modules added scripts or css to the array and it may cause troubles. All that led me to create my own file array for front-end. $config->siteScripts = new FilenameArray(); $config->siteStyles = new FilenameArray(); Now that isn't something other front-end module know of so maybe it again isn't good regarding that, where the core $config->scripts could give a standard, so third party front-end modules could rely on. I just don't think mixing them isn't very nice.

I don't recommend using the config->scripts that core uses. Cause if you use form API or others core modules on front end you will end up having scripts in there you don't want.

https://www.promisejs.org

The recursion happens cause you get the field from pagr which triggers formatValue again. Maybe it's better to get the unformatted value getUnformatted(field) that will get the object with the languages inside or prevent recursion with a marker you set to the page to ignore them. Maybe also a after hook works better as there might be the language module song theit work too. Or set hook to after those of the language modules. I'm still not sure what exactly you try to do and why.

Please make it a possible for absolute path from root. That traversal back with ../../ is not very convenient at all. I have a fork I'm using ever since where I changed it to allow for files outside templates folder using root path. It's an assumption that shouldnt be made in th first place. The hx

Maybe if you could make another example. I think it's a little foggy for me what exactly you mean with local vs hooks or local vs hookable methods? Or do you mean wire('pages') vs $this->pages or $this->wire->pages? Maybe Ryan could answer all those more competently after all.

Sorry don't understand the question. Hook able methods always have some overhead but most of the time it's benefits over performance cause it's so minor you woNT notice. Maybe if a method gets potentially called 1000 times a request you may want to take that into consideration. This code is brand new and not usual at all. I think Ryan does some magic here to account for performance here. But I'm not sure as I don't understand what it does exactly.

Maybe Fieldtype::formatValue to get before output and format it. Like Textformatters.

What is backbone?

On a page field you can configure if it's multiple or single value. If it's multiple it will be a page array and your method doesn't work cause you need to specify which in the array you want the tytle from. if you only need single value you also need to make the field single value.

Is property_category a single reference or multiple?

Ugly things! PW should remove the z-index:0 from #content. No need to add it and if there's a reason it can be solved differently by adding z-index: 0 to footer too, but then why? PW has that wrong not your module or the plugins so PW needs to sort that out cause it's a ”bug". It's like "adding !important to all elements that need overriding specification problems in you CSS". #header (stacking order 1) #content (stacking order 1) #footer (stacking order 1) now a "z-index: 0" to #content will make it #header (stacking order 1) #content (stacking order 0) #footer (stacking order 1) So content is "under" footer now.

But PW has the "<div id='content' class='content'>" with z-index: 0, jquery is fine. I don't see a reason why PW needs a z-index: 0 there at all as it will result all absolute containers inside #content underlap #footer cause #footer has no z-index.

Your last code makes a lot more sense sense. All previous code and errors didn't had any of $header... Then you solution was <php $header=$pages->get('pagenumber'); ?> Which makes no sense. $header wasn't anywhere in header.inc and further $pages->get("pagenumber") doesn't do anything in PW. Now using a integer <php $header=$pages->get(1012); ?> // '1012' works but looks wierd as it's a string and not a number Is a different story as it will load a page with ID 1012. And with the new header include you show posted there's suddenly a $header->scoial_icons etc. Anyway happy your colleague was able to help you out

You just point the two domains to the same root. Then use full http link in your language switch. Simple really (If you use LanguageSupportPageNames)

Thanks Nico. I think we got all sections assigned to someone already but sure there's always enough to do. I'll have a look when I get to it. A good question. The difference is that it's more of a reference with examples for each API method or property. The documentation pages are good to get understanding with examples and the cheatsheet is built from the content from there (just without examples). Idea is to extend it and provide more examples for stuff that isn't covered on the docu pages. See it as a more comprehensive and compact version like the php api pages with comments and cross references. Most important maybe is that we all can edit those and have some cool options that the docu pages don't have.

How does that solve what? This code doesn't do anything. The selector doesn't do anything. And I don't see $header being used anywhere.

Each entry in PageTable is a page and can have it's own template file, just like a normal page. So you can create a template file for each and use the $page->render() to output the markup. Like Martijn's code showed. It's very convenient and flexible reusable. foreach ($page->table as $row_page) { echo $row_page->render(); } the template file for "text" may just contain <div class='row'> <?php echo $page->body ?> </div> And so on.

There's a process configuration now where you can have ui of config.php. read the blog.