adrian

When I was getting this it turned out to be a PHP memory limit issue. What is it currently set at?

I think this is what you need: https://processwire.com/blog/posts/multi-instance-pw3/

Just a quick update to you all know that there is a new keyboard shortcut for reloading a snippet from disk, clearing previous output, and running the code which should be a nice time saver and also prevent you from accidentally running old code in the console that hasn't been updated from the disk version when you are using an external editor. I have also rejigged the execution of code when "Run" is called vs injecting. Hopefully the visual cues of the button changing from "Run" to "Inject" and the status in the header showing "Inject @ Ready" makes it more obvious what is going to happen when. Another update is that the Dumps Recorder panel now stores its data in a file so that it will survive across sessions which may be useful if you are hooking certain session methods and other scenarios where the normal Dumps panel is not showing your bd() calls.

Thanks @houseofdeadleg for those settings. 1) Testing here I am not seeing any problems, but I have committed a new version that should fix that notice that is showing up in your CSV export. 2) The field pairing options are available if you define Configurable Pages under the "Where editing tools are available and separately configurable" section. You then define the field pairing on the settings tab of the page whose children you are exporting. 3) You don't need to share sensitive data - please just create a minimum test case CSV file that shows the problem with only the first line importing. Also, are you on Windows, Linux, or MacOS? I am thinking it might be a lined ending issue. Also, what PHP version are you running?

@houseofdeadleg - can you send me the module settings data - this module (http://modules.processwire.com/modules/module-settings-import-export/) makes it really easy. Otherwise, if you have Tracy installed, open up the BCE module settings page and then open the Adminer panel and copy the json from the data field. Can you also post (here or PM) the CSV that you are trying to import that only imports the first line.

It would be interesting to know more than "everything crashed" ? Different strokes for different folks. PW is not designed for the same developers as Wordpress. Wordpress works easily to a point, then it's really painful. PW is maybe a little too techie for some folks initially, but has so much more flexibility than WP. So "not user friendly" really depends on who the user is - wouldn't you agree ?

Yeah, that makes sense ? Ok, so after spending way too much time, it's not specifically a Tracy issue. If you do a Tracy log call, eg: $this->addHookAfter('Session::loginSuccess', function(HookEvent $event) { l('Session::loginSuccess'); }); then it works fine. The issue is that dumps are stored in a variable and added to as needed during the current request. But it seems like PW hasn't actually started its session at Session::loginSuccess. If you try the same bd() call at Session::init then it works as expected. $this->addHookAfter('Session::init', function(HookEvent $event) { bd('Session::init'); // works }); So, I looked into the possibility of making it possible to do bd() calls and have them carry over to the next PW session (after the login has actually started the session) and there are possibilities, but I think they all come with downsides. I think it might help the Dumps Recorder panel though in that I'll be able to make it keep data over sessions, so I might consider that. I'll mull it over for a bit. As a reminder (almost just for myself), Session::loginSuccess does work on some setups (eg my local dev environment), so there must be some differences in how sessions are handled that is impacting this.

I think there are only two things you'll need to change. 1) The name of the table "field_start" 2) The "name" field/column for the field's row in the "fields" table.

Hey @bernhard - I just tested here with all combinations of the following on my local dev setup (MacOS) 1) SessionHandlerDB on and off 2) Your hook in init.php and ready.php and in the Console panel injected at init and ready In all cases, the bd() shows up in one of the Tracy redirect bars. Then I tried on one of my linux servers and in all tests, the bd() call was never activated. My thought is that it must be something to do with when Tracy is loaded. Because Tracy is loaded by PW's module system, it isn't loaded until site modules get loaded. Ryan made it so that it is the first of these site modules to be loaded which means we can always reliably use it to test development of other modules, but it doesn't load before the PW core which is why it's sometimes impossible to use it to debug the core. All that said, I don't know if load order is the problem in this case, or if it's something else. I'd actually love to know if you see a difference on different servers / PW installs. And anyone else who'd like to test also - it would be good to figure out if there is something consistent with when it does and doesn't work.

Maybe something useful in here? https://github.com/adrianbj/ProcessRedirectIds/blob/master/ProcessRedirectIds.module

Yeah, I don' think MySQL's DECIMAL supports using a comma as the decimal separator. I believe PW needs to handle conversion from comma to period and back again on wakeup if the locale settings require it.

Or perhaps a varchar just to make sure it's not trying to save something that isn't supported by the DECIMAL type at all.

Try changing the DECIMAL ration field from 4,2 to 12,6 or something equally ridiculous to see what it's actually trying to save to that field.

Is it 1.33 whether you're superuser or another role?

@bernhard - isn't this related to:

ACE Editor is what the Console panel uses and it has different modes for different languages and there is also a regular and inline php mode depending on whether the code starts with <?php or not. I have just improved detection of the mode to use when loading up snippets.

Currently it doesn't support it. It's probably a pretty easy hack to make it support your scenario, but also ask Ryan about it in the support board for that module so he knows that users want that functionality.

My assumption was the entryPages allowed selection of users. I just assumed it was multiple users which is why I thought the ->has() approach would work, but if it's a single page, then id === id works, as of course would $user === $page->entryPages But again, I am not certain ?

I have to get off the computer now but for others to help, it would be helpful if you provide the error and also let us know what the setup is for that page reference field - single vs multple etc. Otherwise we're just guessing ?

Try this: if($page->entryPages->has($user))

If it's a Page reference field, then maybe you need: $page->entryPages->id Actually, given that it's Page "s", plural, then you might need: $page->entryPages->first()->id or maybe you need to check if the $user->id is in an array of entryPages IDs?

Everyone, please be aware of this bug in AdminOnSteroids (https://github.com/rolandtoth/AdminOnSteroids/issues/118) that breaks CkEditor fields with this new PW version. You can easily patch AOS to fix it, but be sure to test before you let your site editors find the problem ?

Good to hear ? There's actually another new version just posted which improves ACE mode detection and whether the current code matches the saved version after a page reload.

@EyeDentify - please make sure you have the latest version - this was fixed yesterday, or at least it was fixed at my end. It was a new bug the was a result of storing to the filesystem which was added a few days ago.

You need the include=all in the children selector. $media_tags = $pages->get("template=fundus-index")->children("include=all, sort=title"); You could also find the children directly by specifying the parent in the selector, eg: $media_tags = $pages->find("parent=fundus_id, include=all, sort=title")); replacing fundus_id with the ID of that parent page.