Forum Replies Created

Viewing 5 replies - 1 through 5 (of 5 total)
  • Thread Starter mechamyu

    (@mechamyu)

    (Forgot to mark as resolved)

    Thread Starter mechamyu

    (@mechamyu)

    I could see the files; and yes, I did migrate, today, actually.

    Since I posted this, I read over the support forum other cases like mine and figured out it was an encoding problem as you say.

    I decided then to change all the filenames with accents, dots, and whatnot weird characters myself, through PHP. Therefore, I fixed my issue.

    Here is how I’ve done it, so other people in my situation may do so, if they have to save that time (I have 5 000 media files, the time I spent on this is easily 1/100 the time it would have taken to do it manually):

    So, I basically ran loops in PHP to rename all files.

    Step 1: I created a new folder on a localhost (using WAMP), copied all my /uploads folder in there, iterated in the folders and changed all the filenames with accents, making sure I had removed capitalized letters as well (for Step 2). I did a lot of research online to identify and change *almost-any* encoding to UTF-8, so then I could replace each actual accented character to a sanitized one.

    Here’s a pastebin of the file I ran over localhost: https://pastebin.com/KeLWpv54
    (please disregard my poor folder iteration, I was sleep deprived.)

    The localhost folder I created had basically this code in index.php, and next to it was the /uploads/ folder with all the subfolders and files. When you run it, it echos all the folder it goes through and the files it parses, before/after results, and it puts a reg FLAG on files that had a rename applied (so you can debug them later if something else happens)

    It works by iterating in the /uploads folder, /uploads being the 1st level of folders, then into /year/month folders (aka, all the way up to three level of directories), OR into any /custom folders (two levels of directories). I forgot to process files in a 1 level iteration for WP builds with their files all scattered within /uploads.

    On each files, it replaces (not removes!) all that list of accents that we can see in the associative array at the top. Note: some may be missing (I only needed French ones).

    Then, for Step 2, I used your plugin with the Pro option “Update the references to the file even if the file renaming itself was not successful”. Most of my problematic files were named after the Media Title, therefore I processed ALL my media (not just the ones from the scan; the scan didn’t seem to pick up the media files with accents!) with the default option (Auto Rename: Media Title). The reason I had to remove capitalized letters with my script on Step 1 was because the plugin removed them from the references at this point.

    Finally, when I uploaded my newly-renamed images over to the server in my /uploads folder, most of the breaking pictures were back to normal, aside from a couple which had weird punctuation (dots, especially), which I had to manually change their file names, using the Pro feature (I didn’t feel like doing a regex at this point, but if someone has this issue for more than, say, 50 media, I highly recommend adding a preg_replace for the punctuation i, in the normalizeChars() function of my pastebin).

    Shortly (TLDR), the *references* (not the filenames) were changed with the Media Files Renamer plugin (pro, because you can’t force rename in the free version). I changed all the accent issues through local PHP scripting, and once those were uploaded, the references were successfully pointing to my newly-changed filenames.

    Phew. I hope the process was clear. My only regret is not putting in comments the stackoverflow answers/url that helped me build half of this thing.

    Cheers, hope some of it helps someone else,
    Karine F.G.

    Thread Starter mechamyu

    (@mechamyu)

    note: i did not try to use the error log from the plugin; I meant general errors I generate using php.ini.

    Thread Starter mechamyu

    (@mechamyu)

    Hi Angelo,

    it was a good idea and I did, as well as adding several term-related others:

    $role->add_cap( 'manage_terms' );
    $role->add_cap( 'edit_terms' );
    $role->add_cap( 'delete_terms' );
    $role->add_cap( 'assign_terms' );

    The capabilities are indeed present in the database, but I still fail on being able to access the Menu links for Event Categories.

    Thread Starter mechamyu

    (@mechamyu)

    Hello people who might be reading this very specific issue(s), I have found out what was wrong.

    Turns out, this was 2 separate issues happening. My first mistake was assuming that what crashed the WordPress edit posts fields was also the cause of CFS()->get(relationship) failures.

    The whole ->get() on a certain page were broken. All of them, on the contrary of my original belief where only the Relationships were broken. They were only the most obvious broken items. I’ll come back on this later.

    I figured what was crashing the Dashboard Relationship fields: I had a “posts_clauses” filter that didn’t consider properly some conditions and would crash the SQL query for Relationships (but not elsewhere, where I was needing this modification). I was able to spot this error by activating my error logs, and seeing the SQL issues.

    But this didn’t fix the NULL returned values from CFS()->get(relationship_fields). Turns out that, on the taxonomy page I was using these calls, none of the get’s were working. And the culprit was no other than CFS Custom Category Fields, another plugin, which I was using at version 1.1.0. Turns out that if we were calling custom meta data from categories, it prevented CFS from calling further normal calls later on, and the plugin fixed this very issue on 1.2.0.

    Sorry for the inconveniences and confusion. I know I had a lot of custom stuff going on, and I’m aware it’s very hard to help cases like mine. I’m marking this as solved.

    Thank you a lot for this plugin, by the way! Real life saver.

Viewing 5 replies - 1 through 5 (of 5 total)