WordPress.org

Ready to get started?Download WordPress

Forums

Custom Field Suite
[resolved] $cfs usage inside the_content filter return fatal error (26 posts)

  1. Miguel Peixe
    Member
    Posted 1 year ago #

    Hi,

    I'm trying to use $cfs inside a the_content filter, but I get "PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 125 bytes)".

    Here's a code example:

    add_filter('the_content', 'custom_content');
    
    function custom_content($content) {
    	global $post;
    	global $cfs;
    	$fields = $cfs->get();
    
    	return $content . $fields['author'];
    }

    Any ideas?

    http://wordpress.org/extend/plugins/custom-field-suite/

  2. logikal16
    Member
    Plugin Author

    Posted 1 year ago #

    Miguel,

    Your server has reached its memory limit. You'll need to either increase PHP's memory limit (higher than 128MB), or try deactivating some unnecessary plugins.

    You also could try adding the following into wp-config.php:

    ini_set('memory_limit', '192M');

  3. Miguel Peixe
    Member
    Posted 1 year ago #

    Hi logikal16,

    Actually I don't think that's the issue, using $cfs->get(); on the same post outside the content filter works fine and my memory limit is already set to a higher limit.

    Is it possible that there's a bug on $cfs usage inside a WordPress filter?

  4. Miguel Peixe
    Member
    Posted 1 year ago #

    Even trying to get a single field, like $cfs->get('author'), I get the same result...

  5. logikal16
    Member
    Plugin Author

    Posted 1 year ago #

    Is it possible that there's a bug on $cfs usage inside a WordPress filter?

    Unlikely. It doesn't matter where $cfs is being called -- as long as it gets passed the correct post ID.

    Try commenting out the CFS stuff, and then var_dump($post). Does the correct post get outputted?

  6. Miguel Peixe
    Member
    Posted 1 year ago #

    var_dump($post) outputs correctly.

    It's really strange to me that $cfs->get(); works on single.php template but not inside the_content filter, why would that happen?

  7. logikal16
    Member
    Plugin Author

    Posted 1 year ago #

    Ditto, I've never heard of that before.

    What happens if you try manually passing the post id into $cfs, e.g.

    $fields = $cfs->get(false, $post->ID);

  8. Miguel Peixe
    Member
    Posted 1 year ago #

    Same problem

  9. logikal16
    Member
    Plugin Author

    Posted 1 year ago #

    Are you using a CFS wysiwyg field?

  10. Scott Kingsley Clark
    Member
    Posted 1 year ago #

    I bet my breakfast he is

  11. logikal16
    Member
    Plugin Author

    Posted 1 year ago #

    Thanks to @sc0ttkclark, who pointed out that the WYSIWYG field also uses the_content(), and this leads to infinite recursion. This isn't necessarily a bug, but it does mean that if you want to continue using the_content(), you'll need to modify your function:

    function custom_content($content) {
        global $cfs, $post;
    
        // Only call $cfs->get() once (prevent recursion)
        if (!isset($cfs->the_content_loaded)) {
            $fields = $cfs->get();
            $cfs->the_content_loaded = true;
            return $content . $fields['author'];
        }
        else {
            return $content;
        }
    }
  12. Miguel Peixe
    Member
    Posted 1 year ago #

    Got the issue, but it's still not working.
    It's not preventing the recursion here.

    Can I suggest using wpautop function instead of applying the_content filters to the wysiwyg field? Or making it optional.

    Seems to me that it's a mix of a WordPres and a CFS bug. I think people do put their custom fields data using the_content filter and it should be able to work fine...

    If it helps the discussion, someone also had this problem with the Advanced Custom Fields plugin
    http://support.advancedcustomfields.com/discussion/2245/applying-the_content-filters-on-wysiwyg-fields-should-be-optional/p1

    Thanks a lot for the support. I'm temporarily changing the wysiwyg field code directly on the plugin, til I get a better solution for it. If I put the custom fields directly on the template it'll mess up my theme structure plans :/

  13. Scott Kingsley Clark
    Member
    Posted 1 year ago #

    @logikal16 - Try placing that same kind of logic in your field itself, put store the variable as static in the field type's class, so it's localized to the needs of that field.

  14. logikal16
    Member
    Plugin Author

    Posted 1 year ago #

    WordPress uses a lot more than wpautop to sanitize the_content:

    add_filter( 'the_content', 'wptexturize'        );
    add_filter( 'the_content', 'convert_smilies'    );
    add_filter( 'the_content', 'convert_chars'      );
    add_filter( 'the_content', 'wpautop'            );
    add_filter( 'the_content', 'shortcode_unautop'  );
    add_filter( 'the_content', 'prepend_attachment' );

    Other plugins add additional WYSIWYG buttons / features, which would break it we replaced the_content() on the WYSIWYG field.

    I think people do put their custom fields data using the_content filter and it should be able to work fine...

    I strongly advise against appending your custom fields into a hook (whether the_content or something else). Adding it separately ensures that your CFs are safe from other plugins.

  15. Scott Kingsley Clark
    Member
    Posted 1 year ago #

    What about my suggestion, I think there could be away to put this 'the_content' check internally within the field itself to check if it's going to recurse or not and whether to apply the filters or to pass the value straight through?

  16. Miguel Peixe
    Member
    Posted 1 year ago #

    I know what you mean but it creates lots of other problems for me. By concept the_content filter should be able to increment data. WordPress should have another filter for that, or a different filter to work with non-direct-content formatting. Agree?

    I'm still going to work with wpautop for now, I'll never use shortcodes, attachments, smiles, or anything like that in my wysiwyg...

    Thanks a lot, though :)

  17. logikal16
    Member
    Plugin Author

    Posted 1 year ago #

    @Miguel - I can't speak for the original intentions, but my assumption is that the_content filter is only meant for processing raw body text.

    @sc0ttkclark - It's easier said than done.

    Any custom logic to prevent recursion would have to live within the_content hook function itself. It's not something we can handle entirely within CFS and the wysiwyg field.

  18. Scott Kingsley Clark
    Member
    Posted 1 year ago #

    All you really need to do is check before that the static var isn't active prior to applying the 'the_content' filter, after running it, turn off static var.

    If static var is active, return output w/o filtering, if static var is not active, return output through filter.

    Maybe it is easier said than done, but that could work if I'm not severely mistaken :)

  19. logikal16
    Member
    Plugin Author

    Posted 1 year ago #

    Right, could you provide an example? I was saying that this static var you mention must be set from within the custom the_content callback, which CFS has no control over.

  20. Scott Kingsley Clark
    Member
    Posted 1 year ago #

    *Gets on GitHub*

  21. Scott Kingsley Clark
    Member
    Posted 1 year ago #

  22. Scott Kingsley Clark
    Member
    Posted 1 year ago #

    My solution does part of the work, making sure no recursion happens itself. It's up to the individual developer to handle their own check to make sure they are filtering 'the_content' correctly themselves to avoid filtering twice or more.

  23. logikal16
    Member
    Plugin Author

    Posted 1 year ago #

    @Miguel - this has been addressed, and will be available when the next version of CFS (1.6.4) gets released.

    https://github.com/logikal16/custom-field-suite/commit/783d03b4e500b175c935d989615cc206b29794f8

  24. Miguel Peixe
    Member
    Posted 1 year ago #

    Awesome @logikal16! Thank you very much :)

  25. Miguel Peixe
    Member
    Posted 1 year ago #

    Hey @logikal16

    I saw you implemented the formatting option, but it's a bit buggy.

    First of all, on line 93 of the wysiwyg.php you forgot to put the first parameter on $this->get_option. It should look like this:

    $formatting = $this->get_option($field, 'formatting', 'default');

    Second, the formatting option is being saved twice as an array, so I get this result when I successfully get the data:

    $formatting = array('formatting' => 'none', 'formatting' => 'none');

    Temporarily I'll check the first value from the array, until you upgrade the fixes to a new version. Like this:

    $formatting = $this->get_option($field, 'formatting', 'default');
    return ('none' == $formatting[0]) ? $value[0] : apply_filters('the_content', $value[0]);

    Thanks

  26. logikal16
    Member
    Plugin Author

    Posted 1 year ago #

    Thanks Miguel, I'll get a patch released shortly!

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic

Tags

No tags yet.