adsoink

Adding a comment here because I am seeing the same issue intermittently. Additionally, some images for a new post or page edit successfully upload to S3, while others land in the Media Library.

Anxious to find a fix for this as I’m in the process of redesigning a client’s website, and an action item is to ensure all media is offloaded to S3.

Hi Jory,

Thanks very much for replying, but please note that I mentioned above that embedding via WYSIWYG does work. It’s when the WYSIWYG editor is served by PODS that the embed feature breaks.

To clarify our regression –

• Clean install of WP using the TwentyNineteen theme and no other plugin installed other than PODS, the following was observed:

• A PODS oEmbed field produced the error “Please input a valid oEmbed URL” on tab out of the field. On save, the URL input was no longer visible and was not inserted into the database.
• Following the steps outlined here produced the same behavior as noted above
• Changed the PODS field value to WYSIWYG which produced the same behavior
• Followed instructions/suggestions from the PODS forums, and all failed to save the URL and produced the same error message.

This behavior is not present when using the default WYSIWYG served by the WP core (either Gutenberg or the Classic Editor). Embeds function as expected.

I would spend more time on this, though we are in the throes of moving our web assets out of WordPress. The crux of this ask was more or less to find a quick, easy fix to keep our assets looking fresh despite the transition.

Thanks for the reply, Jim.

This has been examined in multiple ways –

• Clean install of WP, all plugins, etc… in a staging environment, and the embed feature doesn’t function.
• Deactivated all plugins and used the TwentyNineteen theme, and the embed feature doesn’t function
• Attempted to embed via WYSIWYG, and the embed feature doesn’t function
• Used the examples from the PODS website, and the embed feature doesn’t function

Since our last exchange, the client has decided to take videos out of scope for now, and has asked that we move away from WordPress this year. For as much as I’d like to escalate a bug report and find a fix, neither time nor resources are available at present.

Your time is appreciated.

Hey Jim,

Thanks for the reply. The links function and embed with no issue in the regular WordPress editor.

Thanks for getting back with me.

The 404 error wasn’t an issue with the permalinks, but thanks for the suggestion. The problem was with “ur_get_template”. The 404 went away and the content rendered when I changed that call to “get_template”.

Hey Jim,

It was really, really simple and what I think was making it more complex than necessary was sorting a means of integrating/merging the new post type since work is being done daily on the live site, and thereby difficult to freeze it for any length of time.

One thing I have noticed in the last couple of days is that a large amount of our media (i.e. images and PDFs) was duplicated on import. WordPress additionally decided to make JPGs of PDF files, which is odd. All in all and despite a handful of hiccups, the native import feature did exactly what I needed it to.

I did take another long look at those premium plugins, and tried them in a couple different environments before giving up on them completely. They need some love, so maybe step carefully before recommending a $100 solution when the native WP features might be more than enough to get the job done.

Thanks again for your time, Jim.

Hi Jim,

Turns out there wasn’t a need for any of these high dollar, premium plugins. The native WordPress import function worked perfectly. There were a handful of media links that were dropped, but it was a tiny percentage and the native feature worked like a dream.

Off to chase refunds!

Hi Jim,

The data I’m attempting to port over does not exist on the live site at all, so I didn’t have any need for a tool like WP Migrate Pro. It is simply a brand new post type that I need to shift from one location to the next. There are roughly 350 of these custom posts that I need to have be 100% portable, and it doesn’t appear as though there is truly a means of doing it without losing data from the live site (which will amount to a considerable loss).

I did indeed get the structure imported to the live site, and it did “stick” so there isn’t a concern there.

CIO doesn’t show any of the relational data at all. While I have now sussed a means of exporting these custom posts to either JSON, XML, and CSV the import functions in CIO and Import All duplicate all of the custom posts and strip them of the Pods data. Both frameworks appear to also arbitrarily decide to skip either the first endpoint (JSON/XML) or column (CSV), and the imports fail 4 out of 5 times. I could easily push support requests forward, but one would think given the “premium” status and the cost associated that they would work out of the box.

Thanks very much for your time. It’s looking more and more like I need to move on from Pods as a solution for my client.

Hi Jim,

Perhaps a mix-up in language, but to me “structure” is data, and was thereby unable to migrate.

Here is what I discovered since my post –

• CIO Custom Fields Importer does not function as advertised. It deleted all relationships and duplicated all of the posts I was attempting to move.
• UpDraft also does not function as advertised and like CIO, also deleted all relationships and duplicated the posts.
• All Import – same as the above

As for the “Migrate Packages” error, Pods was holding onto previous import attempts without exposing them in the admin UI. I ended up truncating the tables in the database and running the import again so as to get the structure moved over. As for the custom posts, I’m wholly at a loss now that I’m having to chase down several different plugin developers to refund my purchases since all three have effectively killed all relationships and duplicated the posts.

Thoughts?

Thanks for the reply, and the answers to your questions above are all yes. It turns out however the issue is conflict with a Windows VPS on GoDaddy. I wasn’t aware of the client’s server technology until late last night, so I’m working now to move them over to a Linux instance. The VPS is running the latest and greatest PHP but there are some oddball permissions that even when corrected still produced the errors I was seeing.

Thanks!!

Howdy,

Thanks again for the reply. I’m now running with 3.2.1 and I don’t think it’s at all production ready as there are a number of bugs (i.e. when the header is made “sticky” the feature to shrink the logo and tag line actually expands them, and the menu disappears irregularly). I can outline those issues in a separate post, but the function I’m looking for to take the social icons out of the navbar and place them elsewhere does not exist in this iteration of the theme.

My solution yesterday was to create a widget and give it a value of “__before_header”. Where this was working perfectly prior to upgrading to 3.2.1, the widget now appears below the navigation and above the slider. Fiddling with the CSS to reset the display unfortunately does not work. Did something happen with the “__before_header” hook? Is there a plan to provide greater flexibility with the placement of social icons?

Thanks very much for the reply, and I’ll keep my eyes peeled for the update. It hasn’t come through as of yet. I greatly appreciate the CSS suggestion as well. It’s sadly something I’ve already tried and doesn’t move the div in question at all (even after playing with the z-index). I’ve additionally inserted “.row-fluid” into a similar attempt with the same results – .social-block remains nested in the nav.

I have attempted just about everything under the sun with the CSS and nothing works. The issue again is that this function is buried in the following classes: navbar -> navbar-inner -> row-fluid -> social-block. Given that this dynamically generated div is three levels below the parent, moving it via CSS alone isn’t really viable. I additionally tried to hand code the HTML for my icons, but there doesn’t seem to be a place inside the header.php file where I can insert said code that doesn’t ultimately break the desktop theme or the responsive bits.

Let me know when you can what Nic comes up with. It’s really a shame that the social icon display wasn’t made into a widget with more options of placement. More so the heavy lifting to insert new icons (or just modifying the existing ones) as opposed to the “canned” versions that are part and parcel with the theme.

We have a low CTR on the icons for these sites regardless, so the before mentioned wish to place them above the nav is right now a nice to have rather than a deal breaker. This is, however something I will need to dial in before the end of the month.

The sidebar widget worked, so thanks for the suggestion. Given how the site I’m redesigning is actually administrated, folks have access to the widgets so I’ll need to lock down the admin side a bit more unless there is a solution for why the theme blocks the code shown in my example above. Great quick fix, but I’d definitely like to see a little more flexibility.

Just a quick update with the fruits of my efforts thus far today –

After pouring through the function reference I was finally able to mostly remove the function in the parent theme, but in bringing it back (even as a “new” function in my child theme) none of the icons show up in the UI. What’s more is that even after removing the function/action as well as the filter, “social-block” still renders in “navbar-inner” so my effort was moot.

Last piece I tried was to recreate the “class-header-header-main.php” file and manually change where “tc_social_in_header” was being called. This produced no results.

Is there perhaps another set of functions that I’m missing? The client really doesn’t like the view of the social icons nested inside the navigation (with our branding and flow, it is a little messy), hence the ask and the effort thus far. The ability to better specify where the social icons land is really the only detractor to this theme so far. Working with it has otherwise been brilliant, so my hope is that there is a fix and that I don’t have to retread and recreate my efforts inside a different theme (thereby producing several unbillable hours).