DexterG

1.) Thanks for your help and suggestions! Yes, I am using the latest version of the plugin, 2.1.8, and it’s set to auto-update. There are no other plugins active, by the way.

2.) My “test.csv” import file consists of one line and was created and edited in Gedit on Fedora Linux and saved in UTF8 format.

3.) In my testing this morning I am getting the opposite results of my testing yesterday evening! Today ONLY the private_id is being imported or generated, whereas yesterday everything EXCEPT the private_id was being imported and no private_id was being generated if left blank. Your explanation of what SHOULD happen in each of these cases was helpful.

4.) This morning I tried importing several test csv files with “CSV Imports in the Background” turned on, which is the default setting. In each case, no provided private_id, a provided unique private_id, and a provided repeat private_id, the personal_id was handled correctly but the rest of the new record was blank.

Here is the debugging report:

[07/21/22 6:03pm UTC]
xnau_CSV_Import::insert_from_csv

columns:day_id, month_name, day_number, private_id

csv line= Array
(
[day_id] => 01-19
[month_name] => January
[day_number] => 19
[private_id] => BN34MK2 <== Note: This is a private_id that I generated and which already exists in the database.
)
[07/21/22 6:03pm UTC]
CSV import: empty column skipped: day_id
[07/21/22 6:03pm UTC]
CSV import: empty column skipped: month_name
[07/21/22 6:03pm UTC]
CSV import: empty column skipped: day_number

Note: These three fields should NOT have been skipped! This may indicate a bug in your code.

[07/21/22 6:03pm UTC]
PDb_submission\main_query\base_query::execute_query storing record: INSERT INTO wp_participants_database SET date_recorded = “2022-07-21 18:03:45”, date_updated = “2022-07-21 18:03:45”, approved = ‘no’, private_id = ‘Q43NOM3’ <== Note: This is a new private_id that was generated automatically by the plugin, correctly.

Note: As you can see, no data was imported, but a new private_id was generated, resulting in a new blank record except for the private_id field along with the date_recorded, date_updated, and approved fields.

5.) After running all of the above tests, I tried it again with “CSV Imports in the Background” turned off. In each test case, no provided private_id, a provided unique private_id, and a provided repeat private_id, the personal_id was handled correctly and the rest of the data fields were imported correctly. In other words, it worked flawlessly.

Here is the relevant debugging report:

07/21/22 6:43pm UTC]
xnau_CSV_Import::insert_from_csv

columns:day_id, month_name, day_number, private_id

csv line= Array
(
[day_id] => 01-19
[month_name] => January
[day_number] => 19
[private_id] => 123RT45 <== Note: This is a private_id that I generated and which already exists in the database.
)
[07/21/22 6:43pm UTC]
PDb_submission\main_query\base_query::execute_query storing record: INSERT INTO wp_participants_database SET date_recorded = “2022-07-21 18:43:55”, date_updated = “2022-07-21 18:43:55”, day_id = ’01-19′, month_name = ‘January’, day_number = ’19’, approved = ‘no’, private_id = ‘ATOHEP6’ <== Note: This is a new private_id that was generated automatically by the plugin, correctly.

Note: As you can see, none of the import data fields were skipped as they were with “CSV Imports in the Background” turned on.

6.) Conclusions:

In my case, “CSV Imports in the Background” causes problems. Yesterday, it always created new records missing a private_id and today it always created new records missing everything except a private_id. One possible explanation for this discrepancy is that yesterday I was creating test.csv files with multiple records whereas today I used only single record test files. I will have to investigate that further and see if I can recreate yesterday’s results by using multi-record import files.

I am not aware of any caching software running in my WordPress installation or on my hosting service, Hostinger.com, but there could be any number of things happening on the back-end that I have no knowledge of or control over.

What do you think is going on?

That’s interesting. Why is a forward slash used by default on the setting for Default Image path? I used that path as an example of how to fix the upload path.

When I first opened Participants Database after installing the plugin, I was greeted by an error message across the top of the screen saying

The configured uploads directory “/home/215093915/domains/mydomainname.com/public_html/wp-content/uploads/participants-database/” for Participants Database is not writable.

I assumed that this meant that I needed to create the participants-database directory, although nowhere in the setup instructions was there any mention of this. Anyway, even after I created the directory, the error message remained unchanged until I added the forward slash to the File Upload Location path.

I had the same problem. Here is how I fixed it:
1. I signed into my hosting service’s website control panel.
2. I opened the provided file manager.
3. I created the folder that Participants Database was looking for:
/wp-content/uploads/participants-database
Note: No modification to the folder’s rights was required, since it’s inside the uploads folder, all of the required rights were inherited.
4. In the Participants Database settings, back in WordPress, I changed the File Upload Location to /wp-content/uploads/participants-database/. Please note the starting forward slash, which was missing from the default setting. This could be a typo on the part of the developer?
5. After making the two changes described above, I tried uploading a picture as part of a new database entry and it worked flawlessly. However, I did have to increase the File Upload Limit size in Participants Database settings because my photo was bigger than 100 KB.

• This reply was modified 2 years, 7 months ago by DexterG. Reason: corrected formatting error

Yes, I’m having the same problem. I wish somebody would fix this.

I’m running the generic Twenty Twenty-Two theme, and marking a post as sticky has no effect on its placement. They always sort by date. I have no separate home page, just the blog, which defaults as the site’s homepage.

That’s good news! Thanks for letting me know, Alan.

Unfortunately, I shut down the website where I was testing all of this, so I cannot verify that all of the ghost thumbnails that I was getting after a move have been eliminated.

Did you ever figure out why we have to grab thumbnails by their upped edges in order to be able to move them back into the Uploads folder?

You replied a week ago that you were able to reproduce the problem:

Dexter: “I’m using WordPress 5.6.1 and the default Twenty Twenty-One theme”

Alan: “Some thumbnails were left behind when testing with the 2021 theme.”

Now you’re saying that you can’t. What changed?

You also spoke in your previous post of the thumbnails being “moved”. Is this really the case or are they actually being deleted in the old folder and recreated in the new folder? Is MLF doing this or is WP?

Whoever marked this topic as Resolved is a liar because neither of the two bugs (aka programming errors) that I pointed out have been fixed.

Nothing has changed for me. Everytime I move an image from one folder to another it leaves behind all of the thumbnails and creates new ones in the “moved to” folder. This can be verified by running MLF Sync or by looking at the contents of the folders directly with FTP. By looking at the “last modified” timestamps on the thumbnails you can confirm when they are being created.

Perhaps it’s a function of which version of PHP my host/server is running? I just checked and it reports PHP 7.4.14.

Alan, I appreciate your acknowledging that there is a problem and stating that you will look into it. -Dexter

MLF is the only plugin that’s active. I just tried it again with a brand new image that I just uploaded. Same thing happens: three scaled thumbnails of that image in various sizes were left behind in the source folder and three new scaled thumbnails were created in the target folder. I’m using WordPress 5.6.1 and the default Twenty Twenty-One theme, in case you are wondering.

By the way, during my testing this weekend I was able to verify that every time you move an image or group of images out of a folder with MLF it leaves behind a complete collection of scaled thumbnails for those images. Unless, of course, the images are smaller than the minimum thumbnail size of 150 x 150, in which case they won’t generate any thumbnails.

Here is the exact procedure I followed: 1.) create a folder with MLF, 2.) move one or more images (larger than 150 x 150 pixels) into it using MLF, 3.) move all of the images out of the folder using MLF.

Results: The folder will now appear empty in MLF, but if you check with FTP, all of the scaled thumbnails for those moved images are still there in the “empty” folder (bigger images will have more thumbnails because they can be scaled into more sizes). Also, if you press the MLF “Sync” button while viewing the “empty” folder, the program will find all of the scaled thumbnails for the images that were moved out of the folder and display them as new images. It is worth noting that the moved images have new thumbnails that are generated in the folder that they were moved to. This can be verified by looking at the file creation dates with FTP.

Alan P has not responded to this MLF program bug either in the three days since I first mentioned it in this thread. I would like to hear what he has to say about it and hope he is not simply ignoring the problem. The results I got should be easy to replicate by following the steps outlined above.

I was able to verify what you said, Peter S, that dragging images from near their top edge will work, but if you click and drag anywhere else on the image thumbnail it won’t work.

This shows that it’s not an issue with the “uploads” folder itself but with the top folder, positionally, in the list of folders. This could be, as I’ve suggested, due to an interaction between the dragged thumbnail and the “Add File” button which is located right above the list of folders, which could be triggering a mouse-over event on that control. It could also be because the dragged thumbnail is extending outside of the folder display box. It seems that these two possibilities could easily be tested by inserting a spacer above the folders list, effectively pushing them down so that there is no longer any interaction with the top edge of the box they are in or the control located directly above the box.

Apparently, AlanP is the only one who can conduct this test, but he’s been strangely silent for the last three days on his investigation into the cause of this bug. I’m wondering if he’s even planning to fix it, or just sweep it under the run again as has happened for years?

I just tried it im Microsoft Edge, before I was using Google Chrome, and got similar results. One successful move after about 50 tries. Once again, I got the spinner during the move and all the scaled thumbnails were left behind in the “moved from” folder. Shouldn’t these have been deleted? Or why not just move everything together, the original image file and its scaled version? But again, that’s not our main concern right now.

Here’s a thought: I wonder if the thumbnail of the images being moved is triggering a mouse-over event on the “Add File” control which is located right above the “uploads” folder on the screen? Perhaps the solution is simply creating some space, blank or with filler text that could be used for instructional purposes, immediately above the folder hierarchy?

I was able to get it to work twice, out of about 35 tries. I got the spinner both times, which may just be a function of the sizes of the files being moved.

Interestingly, when I checked the folders using SFTP, I saw that all of the scaled thumbnails (150×150, 300×300, etc.) had been left behind in the “moved from” folder and new ones had been created in the “moved to” folder. The file creation dates and times confirmed this. I’m sure this is immaterial to the problem we are exploring in this thread, but I thought it was worth noting while it was still fresh in my experience.

For the benefit of those who will read this thread in the future, I would like to clarify that my initial understanding of the problem was incorrect. Sorting by name in MLF was not causing the image duplication but simply making it apparent to me. Because I have so many images, going back more than 10 years, the duplication was not apparent when sorted by date because the duplicates were spread across multiple pages.

Sometimes there were two, three, or even four registrations in the database of the very same image file! And deleting any one of them would delete the actual file, leaving the additional copies as orphans. I tried running a deduplication plugin to fix this, but since the actual image files no longer existed the program was unable to fix this problem.

And even more frustrating was that if I re-uploaded any of the deleted images the duplicate copies would immediately reappear! That’s because there were still references in the WP database to that file name. What I ended up doing to fix this problem was going into the database directly using phpMyAdmin and searching for and deleting these duplicate references to the image files manually. They existed in both the “posts” and the “postsmeta” tables. This was an all day process but I ended up finding and removing 56 of them. Once I cleaned up the database I could re-upload the images without any of them appearing as duplicates.