Klenkes

Since it remembers which tree is open it's exactly two clicks. Open tree and click on siblingpage. Or do you mean a siblingsview on the same tab as your fields?

@creativejayUntil the new admintheme Reno I thought the same thing but with the modal-flyout-tree it's just as easy.

While importing one image per field works fine I seem to be unable to import multiple images to an image field. The image field has no special setting and importing just one image works. I have tried with different separators(#, ##, \r, |) but to no avail. Strange, because this week I imported multiple values to an option field with no problems. Did I miss something? BCE 1.4.9 on PW 2.8.35 3.0.39

After test importing hundreds of pages in the last days I think BCE is a real time saver! Good job Adrian! I still struggle with one feature though... since I have a lot of ProField Textareas to import to I have to use field pairings which works great, even with images, but the only location to configure field pairings are the parent pages. This means I have to add each and every parent page to "Configurable Pages" in BCE settings. I can work with that but wouldn't make it more sense to make it template related? Since the template defines the fields to use then field pairings would be unique to a template? I think I read something about this before in this thread but cannot find it anymore...

That's strange... I had the same problem with the version 1.4.1(?) but now my version is 1.4.7 and I paste my CSV and it works perfectly. I save my CSV with \r\n at the lines end.

Of course Presto based I am a Presto worshipper since the early days and cannot let it go. I didn't know there is another one like me...

No TurboMode is active and all caching is disabled in the settings. With an open Dragonfly window it works fine but not without it. The strange thing is that It's only an issue with PW, not any other CMS. I looked at the response headers for a looong time but couldn't find anything. And on my local development environment there are no expires directives in the htaccess. It's a mystery to me.

I noticed the same thing. Template changes show instantly but CSS changes can take a few hits on F5 or even hard refresh. But not always... I usually work with Opera 12.18 because I love Dragonfly, Opera's DevTools, but it's not possible with PW. Changes never show, even with diskcache and memory cache completly disbaled. Sadly I had to switch to Chrome but PW is worth the switch.

On PW 2.8.35 this error occurs: Fatal error: Access to undeclared static property: Wire::$allLocalHooks in ... site/modules/DebugPerfmon/DebugPerfmon.module on line 126 $local_hooks = wire('config')->version >= 3 ? wire('hooks')->getAllLocalHooks() : Wire::$allLocalHooks; which most likely results from the >= 3 and doesn't respect the 2.8 branch I changed it to 2.8 which solves my current problem

nav#kotm should get rid of the padding-right 62.5px and everything should be fine. BTW it's in Chrome too.

Haha... that fooled me too! That's because there is no mobile menu to open. The hamburger icon is just an anchor link to the bottom of the page. That is where the menu is already shown. Confusing...

A quick look at http://bielenberg-soerup.de seems pretty okay on an Ipad Mini, both landscape and portrait. http://malabu.de has some issues on portrait because the sidebar menu gets partially covered by the content, but not unusable. You can see for yourself when resizing your browser window!

mhh... still doesn't work in Chrome. In fact Chrome says: $grid.imagesLoaded is not a function, and I couldn't find the imagesLoaded javascript anywhere... I once dealt with Masonry and the trick was to specify image dimensions with the img tag.

As a hint... Masonry calculates the height for the div#portfolio wrong with height:40px;(inspect it in Chrome) and that's probably because the height of the images are not given or not known at the time of rendering. IIRC there is a workaround somewhere in the masonry docs to counteract that. The moment masonry rearranges the elements it calculates and refreshes all the dimensions, and all looks fine. Edit: http://masonry.desandro.com/layout.html#imagesloaded

I just updated an installation on a remote server from 3.0.18 to 3.0.29 and the repeater now works fast as hell! Whatever changed since 3.0.18... it fixed it at least for me. 40 entries, each with 2 textfields and 1 URL field took 7-8 seconds(3.0.18) and now only 1s

There are no copies of the editor. /wire/modules/ is the core of CKE and /site/modules/ is the place for stuff specific to your site, like custom Javascript, CSS and plugins. See config TAB of your fields. The folder called ckeditor-4.5.3 is the core of CKE with all its own functionalities. I wouldn't touch it or you will have a problem when upgrading PW. Files like InputfieldCKEditor.module are the integration of the editor into PW .

I work on Windows too and my paths all show with backslashes: Compile Error: require_once(): Failed opening required 'xxx.php' (include_path='.;d:\projekte\test\') (line 40 of D:\Projekte\processwire.kopfleere\www\site\templates\_head.php) But I don't know about xampp... anyway... Failed opening says that either the file doesn't exist or the path is wrong or invalid maybe due to a htaccess directive?

Welcome to the forum! Just put this in your _main.php where the footer is: $footer = $pages->get("1036"); And you have all the fields of your footer page. (you can omit the id= in your selector) Then output your fields like that: echo $footer->yourfieldname; It's just one way of doing it.

Your set lifespan for the cachefiles has nothing to do with the expire dates of the report. In ProCache settings on the TAB GZIP-More there is a link to a sample part of the htaccess addition: Place the contents of this file... Copy the content and place it at the beginning of your htaccess. That's it.

How about that: $date = strftime("%d. %B %G", strtotime($page->date)). "-FR/DEFAULT"; Solved the month problem for me.

I just recreated the setup in DEV 3.0.5. Same fields(3 input type text) in a repeater, 40 entries = 120 fields With the standard options for repeater fields: Repeater item visibility in editor New items open, existing items collapsed (recommended for most cases) Repeater dynamic loading (AJAX) in editor Existing and new items (recommended, especially for repeaters that might have LOTS of items) PW 3.0.5 opens and saves the page 30% faster. Which is in my case 7-8 seconds instead of 12 seconds. I think, that's okay. BTW... the new repeaters are great! Making entries hidden is a great feature!

Updating to PW 2.7.2 didn't change anything.

Ajaxloaded repeaters sound interesting! And you are right. If possible, pages are the way to go. Nevertheless I was eager to know why I didn't work for me. So I tested it on an old PW 2.6.1 install and it worked fine and fast. Approx. 3 seconds to save. Then I upgraded to PW 2.7.0 and the same page took 12 seconds to save! 40 repeaters each with 3 simple text fields of text like names. Strange.

The 3 fields were all input type text and like: John Smith for a name ant the second field like : D, E. Third field was supposed to hold the emailaddress but was almost empty for all the entries. I couldn't find a solution to the problem so I got rid of the repeater field and created the content with pages. Which is PWs strength anyway. But thanks.

For a school project I want to list all teachers on a page with their names, subjects and email addresses. I created 3 inputs, put them in a repeaterfield and created approx. 50 entries with teachers.(but only 5 email addresses) Frontend is rocketlike fast but in the backend the page takes more than 10 seconds to load AND save. I know, repeaterfields are not meant to hold large amount of content, but 50 entries? Not that much. The page in Admin -> Repeaters says under: Process "0" Is that correct? Or is that behavior normal for a repeater field? PW 2.7.0 Repeater 1.0.2