Admin form entry not showing on page

Where is this text coming from? Custom field? Post content? Somewhere else?

If it is in content with all the other stuff, does it always occur in the same position relative to the other content? If so where or how do I identify it? Before the images? Before the UL? After? In a particular span or div or UL etc.? Is there any other content it needs to be separated from? How is that content identified?

It may be simpler to post a copy of the raw text used to make your sample image.

Yes, what you enter, but copied from the text tab so all the HTML is included. What I’m really after is what is in the post_content field of the DB, but I can’t easily explain how to get to that. The text tab is usually the same thing.

Yes, the preg_match() line is what you need to edit, then the description will be in $matches somewhere. Regexps (the ><\/*>< stuff) are certainly mind boggling to the uninitiated. I myself am still not that confident with them.

FYI, for any part of the regexp string that is in parenthesis, and where a segment of the content matches the contained regexp fragment, that matched segment gets assigned to the next available element of $matches. Right now the first two parenthesis groups match the img and linked img tags, so they are assigned to $matches[1] and $matches[2]. Similar for the ul tags.

The .* portions between parenthesis groups match anything but are not assigned to $matches. But, for example, if your description occurs after the linked image tag tag and nothing else occurs until the first ul group, changing the current .* to (.*) would match your description and add it as $matches[3]. The subsequent ul matches move from 3 and 4, to 4 and 5.

If the description cannot easily be separated from other text, you may need to place it in an ol block or similar. the ol tags are easily stripped out again if they do not normally occur anywhere, making finding them unambiguous. The delimiting tags do not even need to be valid HTML since they are stripped out, though be wary of the WP content filters.

Another thing that really helps is a regexp fiddle tool. Perhaps with the above info and this tool, you can figure this out on your own. The above tool does not accept the ‘s’ flag (the final ‘s’ in your regexp), so you’ll need to remove any newline chars from your sample to simulate the ‘s’ flag. Hover over the matched portion to see how the sub-matches are assigned. If you still can’t figure this out, go ahead and post the raw text and I’ll try to help you out.

I’m wondering if this sort of setup is really the best approach for you. On one hand, it’s fine as long as it works, and if you have a lot of data configured this way already, it may not be worth converting. (but possible with a custom script) I can see doing the images this way because of the media manager tool.

I would have suggested the UL lists and the description be managed as custom fields (or even a metabox) instead of placing them as part of the content. Matching HTML tags like you are doing is rather fragile. If someone should forget some crucial part of the structured content, the entire thing falls apart. By placing the various parts in dedicated fields, they are no longer interdependent and any input errors are limited to the error itself, not affecting other elements.

The custom fields serve as sort of a reminder of what data is needed, and the specifics of where and how the text is marked up can be relegated to the template instead of it being required to make the whole thing work.

This is just a suggestion of course, there is no need for you to consider this if you do not want to or if it’s too much bother. When I see what I think is a better way to do something, I have trouble not saying anything. I also have no trouble having my ideas ignored if they are not liked. It’s your site after all, not mine 🙂

Thanks for the explanation, I didn’t realize how heavily altered your admin input forms are. I’m also pleased to hear you have intentions to improve the way the site works. Things aren’t as bad as I had feared, but I’m still not thrilled with extracting portions of data with preg_match(). While it’s a very powerful and useful function, it’s not very efficient. I recommend you eventually move away from storing and retrieving data by position of HTML tags in the content.

Another possibility that is closer to the current setup than my earlier post meta suggestion is to continue to use post_content, but organize the data as an associative array that is serialized before storing in the DB, then unserialized upon retrieval. Depending on how the data is stored, serializing and unserializing may be done automatically. Don’t worry if you don’t understand this now. Just bookmark this thread for future reference. When you’re ready for a better storage structure, come back here. It’ll probably make sense by then, and you’ll find it’s a good idea 🙂

Thank you for trying to get the information I asked for, but unfortunately your efforts did not give me what I need. I’ve another idea for getting the information. This is only required if you cannot figure out this regexp thing on your own from the previous information. Add the following code to the snippet you provided in your initial post. Insert it after the first <div class=... line and above the <?php preg_match(... line.

<pre style="width:80em;">Content Data>>>>>
<?php echo "\n"; var_dump($content); echo "\n";?>
<<<<<<End Content Data</pre><br>

This will mess up your page layout, but produce the information I’m looking for. Once you’ve copied the output between the angle brackets to a post here, you may delete the code to restore your page.

Use this for the regexp in preg_match():
‘/(<img[^>]*\/?>).*(<a.*<img[^>]*\/?><\/a>)<\/p>(.*)(<ul.*<\/ul>).*(<ul.*<\/ul>)/s’

The description will be in $matches[3]. Make the UL indexes 4 and 5 instead of the current 3 and 4.

The $matches[3] description contains the following HTML tag when you look at the source view:
<p style="text-align: justify;">

Before echoing this value, use str_replace() to insert additional style directives, like so:
echo str_replace(';">', '; width:260px;">', $matches[3]);

I must say this is quite weak, fragile code, intended mainly to get something working for you. It’s assuming the style attribute will always be the final entry in the tag and that double quotes are always used. For that matter it is assuming a styled tag always exists. This is just furthering my original objections to organizing data this way to begin with. Consider this a very temporary solution.

A slightly more robust solution would be to insert a class attribute in a similar manner and apply a CSS directive for that style on a CSS sheet, or at least an inline style block somewhere.

Tip: When you get a blank white page, as you know, it is because of some error in the code somewhere. You can get a better clue to what and where the error is by defining WP_DEBUG as true in your wp-config.php file.

You’re most welcome! I’m glad I was able to help.

I should have mentioned that defining WP_DEBUG as true on a live site is considered a slight security risk. You shouldn’t leave it defined as true for very long if your are not actively trying to debug something.