Unparsed images in WYSIWYG (Fuel CMS 1.0)

edited September 2013 in Modules
In a simple module with a CKEditor WYSIWYG field I can add images through the add image tool button, and invariably, the images will display in the WYSIWYG editor area, and on first save, they will also appear on the view pages. Subsequent edits will still show the image in the editor, but not in the view, where the HTML img tag is rendered like so
img class="img_left" src="{img_path('uploads/lr_pa.jpg')}"

What can I do to fix this - if I put the full image url in, that will work, but is likely replaced on a later edit back to the img_path() version.

Comments

  • edited 6:34PM
    Try adding the "parsed_fields" property to your model to tell FUEL to parse the field value automatically. It doesn't do it by default. It also needs to be done for any magic method calls to the field. For example, in your model, add the following at the top where the properties are declared (substitute "my_field" with your field name):
    public $parsed_fields = array('my_field', 'my_field_formatted');
  • edited 6:34PM
    I'm afraid that didn't work.

    public $parsed_fields = array('content', 'content_formatted');

    The images are in a field "content". They are added with the regular asset button in the CKEditor. I mentioned the module was simple - I'd forgotten! It's an advanced Fuel module.

    In the view, I've tried with just the regular view variable name - eg $content as well as fuel_var('content'). Both render the image tag with the src attrib unparsed as eg: {img_path('uploads/lr_pa.jpg')}
  • edited September 2013
    On a slightly related note (ie parsing WYSIWYG content), in another site using a more recent Fuel CMS v1, I have the CKEditor plugin "oembed". In this other install, the plugin works really well, but on the present project it was throwing up "parseHTML() is not a function" errors. Sure enough, when I checked the jquery file used in the admin, parseHTML() was missing from it. That is the jQuery 1.7 that the current commit has. I updated the jQuery file to 1.8 and that now has parseHTML, and the error has gone.

    Just thought I'd mention it.
  • edited 6:34PM
    The previous suggestion was if you were using a simple module to contain the data. For example, the blog_posts_model that has a content field that you want to display the content like so:
    <?=$post->content_formatted?>
    I guess my question is, how is this content from the database making it's way to the front end. Can you use the "parse_template_syntax()" function?

    With regards to the jQuery issue, it's on our list to update. We've tried a couple times in the past but ran into issues with things like the drag and drop sorting used for the template field type and haven't debugged it yet.
  • edited 6:34PM
    Yes! parse_template_syntax() does the trick. (Note to self - read all CI libraries!).

    Thanks!
Sign In or Register to comment.