Support

Account

Register Login

Forum Replies Created

  • If anyone is still having a problems with this, one thing I noticed that was caused an issue with uploading SVGs is the lack of a proper <xml> tag at the start of every SVG file. So now I make sure to add a <?xml version="1.0" encoding="utf-8"?> to the start of every SVG file.

    Also, I make sure to have height, width and viewBox declarations in the opening <svg> tag as well. So something like <svg xmlns="http://www.w3.org/2000/svg" width="100" height="200" viewBox="0 0 100 200" xml:space="preserve" y="0" x="0" version="1.1">.

    Since I started doing that, I haven’t had any problems with uploading SVGs.

    TIP: I’d also recommend to install an awesome little plugin called Safe SVG, which adds secure SVG upload capability to WP, and as a bonus helps display SVGs properly in the Media library. Otherwise your Media Library will be filled with a bunch of generic WP placeholders, instead of actual SVG image thumbnails.

  • Hi,

    Can someone please give some clear examples (or point me to an article) of why/when one would use ACF Gutenberg Blocks vs using regular ACF Fields (i.e. metaboxes)?

    Besides an obvious visual appeal of ACF Gutenberg Blocks, I can’t help but focus on the fact that Blocks store data as HTML comments in the post_content, while regular ACF fields store all data as separate entries in wp_postmeta. And that’s a pretty huge difference. So I want to understand all of the nuances, advantages & disadvantages of each method. Has anyone written a detailed article with a breakdown of each method, when/where it’s appropriate to use them and what limitations each method has?

    I already can think of a few issues, but maybe I am missing some, so I want to reference other people’s opinions.

    For example:

    1) When it comes to Blocks, it seems that they would be much faster at data retrieval by default. Because the data is stored as one big “blob” inside post_content. Which means that there is theoretically only 1 database query to get all of the content & custom field data. So that means that if you intend to have complex pages with lots of ACF fields, you should use Blocks. So that’s a clear advantage over regular meta fields.

    Or is it? Because yes, if you use regular ACF fields and a default ACF get_field() function, that would query wp_postmeta for each piece of data separately. Which is bad (possibly even very bad). But if you use `<a href=”https://developer.wordpress.org/reference/functions/get_post_custom/”>get_post_custom()</a&gt; you’ll get all of the postmeta data at once and not suffer any performance punishment whatsoever (since that function also caches data, so it’s lightning fast for each consecutive request).

    So seems like performance-wise both can achieve the same results. Or am I wrong?

    <strong>2)</strong> Blocks seem to have a downside to storing all of the data inside post_content, because (a) I can’t easily query that data from another page/post and (b) individual custom fields are not de-coupled from post content. I’ve read the Q&A that said that I can “load the post_content of a given post, and then parse the blocks using the parse_blocks() function” which seems reasonable, but how efficient is it? Also, if I wanted to pull a dozen pages somewhere, based on a matching meta field value, that would be pretty easy & “cheap” (resource-wise) to do with a custom WP_Query. What about doing it in Blocks? How expensive would it be? Would that be even possible? Seems like I’d have to pull ALL posts, loop through each one, run parse_blocks() on every post and only that way I’d find the ones with my desired custom field value. Seems like that would be super expensive & CPU time consuming to do.

    Or I am thinking about it completely wrong and my use-case for Blocks is completely inappropriate?

    <strong></strong>3)</strong> Another issue I can see is if data is hardcoded into post_content, does that mean that I can’t change a custom field output type (i.e. let’s say I want an ACF file field to now return attachment ID, instead of a URL). With regular fields, I can just use get_field('field_name', $post_id, true) and get the ID no matter what and manipulate it how I want. But if it’s saved in a Block as a URL, does it mean it’s hardcoded into the page and the only way to change it is for me to update the block template & then also manually update/re-save every page where it was used?

    I think most of these issues stem from my lack of understanding where I should be using Blocks vs Meta fields. Hope someone can enlighten me.

    Cheers,
    Alex

  • Hi Kevin,

    Was searching for different stuff on the forum, but stumbled onto your post, so thought I’d give my 2c on the topic. Not even sure if you are still looking for input..

    TLDR: definitely drop Divi & go with Oxygen. At the very least, it’s gonna make you a better web dev. Also, no matter what, you final website IS GUARANTEED be lighter, faster & more efficient with Oxygen than anything you can achieve with Divi. Oxygen also has integration with ACF and it’s handy (Divi has it too as you are aware), but it’s only useful for simple ACF field types. So I don’t use ACF integration features at all in Oxygen – I just use a raw PHP code block inside Oxygen (it’s a special core builder element) to define the EXACT HTML output I want, no matter what types of ACF fields I use: simple, dynamic/complex – it doesn’t matter, since I code how to retrieve & manipulate the data. Divi doesn’t let you do that. Oxygen does.

    I’ve used Divi for years, so I know it inside and out. It’s a decent tool for marketers, who need to spit out quick landing pages without having to call their dev all the time. But it just doesn’t cut it for “real” websites, in my opinion. If you are gonna try to build anything remotely custom or tailored to your client, you are gonna end up jumping through so many hoops with Divi, that you might as well build the site from scratch.

    With Oxygen, you are sort-of creating it from scratch to begin with, but it gives you complete creative freedom to build EXACTLY what you want. And, if you know what you are doing, it will result in a much cleaner, faster, more efficient website, that also feels bespoke to your client (combo of Oxygen + ACF + CPT UI/custom post types). You just can’t get that kind of quality out of Divi.

    I also can’t believe how much faster my sites are now, when I’ve switched to Oxygen and away from Divi. It’s no joke. I couldn’t get these kinds of improvements with Divi, no matter what kind of server I had, optimisation I applied or caching plugin I’ve used. My bigger, more complex Oxygen sites run 10 times faster raw (i.e. un-optimised/un-cached), than my past small one-page Divi sites run with all compression/optimisation I could come up with. And that’s a really big deal. Google/SEO will reward you for that.

    So, if you do it right with Oxygen, the resulting site will be just as good as a site that’s built completely from scratch using your own custom theme.

    Hope that helps!

    Cheers,
    Alex

  • Has anyone figured out a solution for this SVG problem?

Viewing 4 posts - 1 through 4 (of 4 total)