Admin form entry not showing on page

https://crankshaft.net/wp-content/uploads/Untitled.png

an image of the form screen and output 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 it will always occur in the same spot.

right now it goes; image1, image2, ul1, ul2
I want it to go image1, image2, description, ul1, ul2

As far as I can tell the line of code is
<?php preg_match('/(<img[^>]*\/>).*(<a.*<img[^>]*\/><\/a>).*(<ul.*<\/ul>).*(<ul.*<\/ul>)/s', $content, $matches); ?>

But I am lost with all the ><\/*>< stuff. and I don’t know what to call the text to reference it…
I could put the description in an OL to make it more identifiable, I would just need the list formatting removed before placement in the page

and what do you mean by raw text? what I enter in the admin form?

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 ??

Thank you for your response. It is a thorough and good explanation. I understand about 80% of it.
I agree and would rather get rid of this if I could, But I am just learning my way around WP and am using the process of making it work correctly to learn how to do it better. And I can’t start cutting out sections until I see how it interacts with everything else. REDESIGN of the site is definitely part of this process but it will come as I proceed.

Hopefully I can answer the parts that you need by explaining the process on my end a little better.
It appears that the person who set the site up did design a custom theme.
in the functions.php (I think) it adds a basic page entry form (pic1 and 2) called “Product Listings”. this form serves to add content to the pages. I can select which page on the form. The Script separates between the “products” page and all other pages. On the Products page I put our different divisions and their applications. the other entries are funneled into sections on the individual divisions pages to display machines.
in the products.php I see the code that I put in my first post. which applies to the “product page” which generates this page (pic3)

As far as a text tab, i don’t see one. I will provide the page source code and a link to the page if you can find it in there. (I think that is what you are asking for.)

https://crankshaft.net/products
https://crankshaft.net/wp-content/uploads/PIC-3.png
https://crankshaft.net/wp-content/uploads/PIC2.png
https://crankshaft.net/wp-content/uploads/PIC1.png
https://crankshaft.net/wp-content/uploads/PAGESOURCE.txt

If you neeed anything else to figure it out let me know… I will fiddle around with it as I get a chance today, using what I understand about the regexp you explained.

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.

I am still having trouble with the regexps. I did what you suggested with putting the line of code in and getting the response:

https://crankshaft.net/wp-content/uploads/products-test-text.rar

I saw that when I did that the description that I had entered into one of the forms showed up where as it doesn’t when the page is normal. Just have to figure out how to call it up.

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.

ALL MOST THERE!!! I took your code and put it in and nothing showed, but i played around with it (hoping to get lucky) and now it shows but there is a formatting issue… if the description line is short (less than 260 wide) all is good but if it is longer it pushes everything down.

https://crankshaft.net/products

I put an “echo $matches[3];” in the div for the images (i figured that would put it below the images) but it isn’t keeping a 260 width limit. I know basic styling but if i put a “style=”width: 260px”;” before the echo nothing shows up on the page again. what would be the context for setting the style width (or any other) in there?

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.

Thank you so much. You have definitely gone above and beyond to help me get this thing going.
And, I will agree, again, with you that this is set-up isn’t ideal. My plan is to get this to where I want it for public consumption and then I can at my leisure build a site from the ground up.
And thanks for the debug tip, I wasn’t aware of that ability.
All the best to you.

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.