adrian

@bernhard - available in the latest version.

@artfulrobot @ryan - I wonder if some of the new techniques described here would help?

Thanks for the help debugging @elvina - I have a new version which should work for you. Note that at the moment it will only work if your CSV has an empty column for the image field, but I also have the code in place to support importing images and files, but there is a bug in the Table field which I need to get @ryan to fix before it will work. Here's the report I prepared for Ryan which includes a hacky fix to get things working if you do want to import images:

That line #1189 suggested there is an image subfield/column involved: I wonder if there is some old image field that wasn't properly deleted. If you look at the database table for the table field, does it contain any unexpected fields? Or maybe the json settings for the field have reference to an image field? Can you please try on a new table field built from scratch with just the fields you need and see if that still has issues?

It looks to me like it has something to do with your table settings under the "What pages should be selectable?" section. Can you try a simple example with just a template, eg: If that works, then maybe you can help to figure out what selector is causing the issue.

Hi @elvina - sorry, but I am having troubles reproducing this - I have successfully imported and Page Select columns matched the page based on the title I entered in the CSV. Even if I enter a page title that doesn't exist, I don't get that error - the row just doesn't populate anything for that field. What version of this module and FieldtypeTable are you running?

Hey @ryan - sounds like a potentially useful input for certain needs. I am wondering what you think about the option of the closed label being something like "3 of 50" or "3/50" because I think in some cases it's important to know if all are selected vs a limited selection.

Seems to be creating quite a bit of excitement. @ryan - not sure yet how much of a performance improvement this might be for PW, but definitely worth looking at.

Hey @Robin S - yep, all you need to do is populate: $this->output = 'this'; $this->output .= 'and that'; return true; inside the executeAction() method.

Thanks Ryan for your hard work getting things ready for 8.4. While I see your frustration with PHP's change here, and appreciate your humorous commentary, I do actually think it makes sense when you consider that null is not a string or an array or some PW object, so there needs to be some way to explicitly state that null is an allowed option, rather than implicitly allowing it, which is exactly what the error states: "Implicitly marking parameter $var as nullable is deprecated". I actually think I prefer the use of union types, eg: (PageArray|null $items = null) rather than the obscure question mark, but as we figured out, that requires PHP 8. Anyway, thanks again for getting this implemented so very quickly so we can all start proper testing of 8.4 with our projects.

Hi @gebeer - please try the latest version. I have modified to use $_SERVER['REQUEST_URI'] which I hope should solve things when you guys have these unusual redirects in place and well as @Jonathan Lahijani's issue from here: https://github.com/adrianbj/TracyDebugger/issues/96 Please let me know if you can now work without that modification to your hook.

Hi @nurkka - thanks for narrowing it down. The current version uses: $config->urls->root which in most cases should return "/" but it was changed from "./" to fix this: https://github.com/adrianbj/TracyDebugger/issues/96. I am curious what crazy redirect stuff you have in ready.php that works with "./" but not "/" though. Can you figure out something I can change it to to work with the redirects you have?

Interesting - does the console panel work when you using it from the PW admin, rather than the frontend of the site? If you can't figure out the issue, perhaps a trial and error approach of going through the Tracy versions to see where the issue starts occurring might be the quickest in the end. Choose a version in the middle between the current, ie 4.26.34 and if that works, split the difference between it and .42 but if it doesn't, go for .30 - you get the idea and hopefully it won't take long to figure out which one breaks things.

Hi @nurkka- sorry you're having issues. Can you please try if a modules refresh fixes things?

The issue would have been that empty line - the blank string in the dump in your screenshot. Not sure why that would have happened - if you see it happen again, let me know and I'll adjust the logic to handle it, but it seems like a weird anomaly rather than something that happens normally.

Hi @Stefanowitsch - can you take a look at the *.log files in site/assets/logs/tracy - each line in the files should start with something like this: [2023-07-18 07-59-40] Do any of the files have lines that don't have this? You could also add: bd($entry); after line line 67 in that TracyLogsPanel.php file and review the entries that are dumped to see which one doesn't have the date in that format so we can attempt to figure out how that might have happened.

@JayGee - not currently. I wonder if the best option might be to make protectedCheck() hookable and then you could add an exception for the required page via a hook in ready.php

That does all sound very weird, but I don't think it has anything to do with the point I made (that you quoted above) which is about editing things like the title, name, or status in the "Edit child pages" table - those are what would be overwritten if not saved before opening a child page for editing or viewing in the same tab - make sense? Do you have Ryan's User Activity module installed by any chance? I wonder if it's perhaps dynamically updating things? Otherwise I really don't know, but I also am not sure how it could be related to this module because we are of course just editing in a modal window which is an iframe of PW's page edit process. I don't think any sort of browser caching could impact this, could it? Unless changing this line: $this->editedPage = $this->wire('pages')->get($id); to $this->editedPage = $this->wire('pages')->getFresh($id); And maybe this one: $cp = $this->wire('pages')->get($id); to $cp = $this->wire('pages')->getFresh($id); fixes things?

Understood, but I think the default should be modal to be in the spirit of editing child pages in the one place without opening a page in full. If you have edited the fields or statuses within the children's table and not saved, and you open a child to view you would lose those changes - hence the need for new tab or modal.

That should be solved with the latest dev version of PW anyway. As for other issues, I am not sure if there are any core ones, but it's still very possible to trigger in your own application code.

Just the last comment: https://stackoverflow.com/a/79072359/1524576 As for whether this affects you, it depends on the version of apache you're running. The current version (2.4.62) still has the issue, but Ryan implemented a fix for embedded links in RTE fields with ? in the URL. It still impacts the UserActivity module unless you hack it. When the fix makes it into Apache will depend a bit on your linux distro unless you compile and update yourself.

Just a little more info - https://stackoverflow.com/questions/78729429/403-forbidden-when-url-contains-get-with-encoded-question-mark-unsafeallow3f The last (current) comment about Craft's rewrite rule shows that this bug is starting to affect a log of people.

Hi @MarkE - this was all done a long time ago before the pw-modal class was available, but the key reason a modal makes sense for editing is that any changes you make while editing in the modal are applied immediately in the row of child page in the table of children once the modal is closed, so I don't think it makes any sense to have different window opening options for editing. But for viewing pages, I always thought that would be better in a new tab, but I suppose a modal or panel might be preferred sometimes, so what about this solution which matches the default behavior of PW's page list action buttons by allowing you to open in a modal with a long click, but still open in a new tab so you don't accidentally lose any changes to other pages in the child editing table? $cp->viewable() ? ' <a class="pw-modal pw-modal-large pw-modal-longclick" href="'.$cp->httpUrl.'" target="_blank"><i style="cursor:pointer" class="fa fa-eye"></i></a>' : '', Just playing around with this and for some reason the pw-panel class doesn't work, but pw-modal does. Maybe it's not being loaded for some reason in modules.

Thanks @MarkE - 1, 2, & 3 all look to be working great now! As for 4 - sorry, I hadn't looked at your code well enough to see those restrictions on the key name - looks like a solution that should work often enough to be OK. Would you like to send me a PR? Thanks again for this - should be an awesome improvement.

@mel47 - please test the attached version. There is a new option (on the Input tab of the field) for "Allow formatting characters in Input, eg. - ( ." Note that unlike the "Letters" option, the formatting characters will be stripped before saving to the DB. FieldtypePhone.zip