Forum Replies Created

Viewing 7 replies - 1 through 7 (of 7 total)
  • Thread Starter colins

    (@colins)

    I rolled back to version 1.6.5 and it behaves exactly the same. I don’t know what is going on, the import worked fine for me a week ago, in the manner described above, and now it doesn’t any longer. Last week I never touched the “Don’t add Empty value fields in database” flag, and the field was always created even for a 0 value, now it is only created (but empty) if I uncheck that option.

    Is it possible that something else has changed w/respect to the default value of this meta field in the new or updated user record, before your plugin ever goes to try to set it? This is an ACF field, if it matters.

    Thread Starter colins

    (@colins)

    Thanks, I figured that out after looking at some comments. But I don’t really see it as an option. All my normal text then runs together, and I have to manually wrap text myself with ‘p’ (looks like ‘br’ gets stripped too). Ideally, I think the autop functionality should be able to handle ‘pre’ tags and not touch anything in there…

    Thread Starter colins

    (@colins)

    Doing some reading, I guess this is related to the ‘autop’ function that adds ‘p’ elements automatically? It seems like the ‘p’s are only added when there is a blank line in the text inside the pre (i.e. double new line).
    I figured out one workaround, which is to add & nbsp; at the beginning of all blank lines, but it would be really nice to have WP automatically stop adding the ‘p’s inside the ‘pre’ tag, since the whole point of the ‘pre’ tag is that it is already formatted.
    Regards,
    Colin

    Thread Starter colins

    (@colins)

    Ok, that xml fragment got almost all swallowed. Let’s try again
    <pre>
    <props>
    <prop key=”get*”>PROPAGATION_REQUIRED,readOnly</prop>
    <prop key=”find*”>PROPAGATION_REQUIRED,readOnly</prop>
    <prop key=”load*”>PROPAGATION_REQUIRED,readOnly</prop>
    <prop key=”store*”>PROPAGATION_REQUIRED</prop>
    </props>
    </pre>

    Thread Starter colins

    (@colins)

    Scott,
    It almost works, but does seem to have a weird issue where it eats some <props> tags. I have a big post with mixed text and xml fragments. The following
    <pre>
    <props>
    <prop key=”get*”>PROPAGATION_REQUIRED,readOnly</prop>
    <prop key=”find*”>PROPAGATION_REQUIRED,readOnly</prop>
    <prop key=”load*”>PROPAGATION_REQUIRED,readOnly</prop>
    <prop key=”store*”>PROPAGATION_REQUIRED</prop>
    </props>
    </pre>
    (don’t know if the comment parser here will kill the stuff above) comes out with the ‘props’ elements taken out for some reason. In other parts of the post, the same thing was happening initially with the same elements, but now it’s ok. I have no clue what is going on. I can mail you the whole post if you wish to try it out…

    Thread Starter colins

    (@colins)

    Yes, that’s one solution. I was actually looking around in the meantime for some online service to escape XML/HTML.
    It would still be nicer if this could be handled in WP directly though, as it’s still not very convenient to if you ever want to edit the original text. You basically have to copy the output text, modify it again, and then re-escape it and put it back in. Pretty laborious…
    Colin

    Thread Starter colins

    (@colins)

    Actually, the behaviour above is with the Textile plugin enabled. With it disabled, wrapping the xml in ‘pre’ tags alone does not work, since the xml is sent out as is and confuses the browser, while trying to add a CDATA inside the ‘pre’ tags also doesn’t work, since it seems WP escapes the CDATA element by adding a space after the initial ‘<‘.

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