How to display Images for an Article?

[DoubleDee]

I am trying to come up with a more sophisticated way to display and store Images for my Articles.

Here is my current set-up..

- Images are stored in an "images" directory.

- Articles are stored in MySQL.

- For the Article "body", I have a field which holds the Article itself, but in a marked up format like this...

<img class="noborder" src="/images/PostageMeter.png" width="150"
alt="Picture: Postage Meter.  Credit: John Doe, Wikimedia Commons."
title="Picture: Postage Meter.  Credit: John Doe, Wikimedia Commons." />

<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus suscipit mattis laoreet. Quisque convallis elementum scelerisque. Nullam accumsan, purus in condimentum placerat, eros lorem pellentesque justo, eget ullamcorper purus felis et magna. Mauris blandit feugiat semper.</p>

<h3>Time is Money!</h3>
<p>Proin viverra vestibulum velit quis dapibus. Maecenas mattis mauris id eros mollis nec venenatis est faucibus. Maecenas fringilla eleifend tellus, vitae gravida purus rutrum non.</p>

- Storing the Body Text and HTML together in a database field works just fine. (However, I am wondering if it might be better to break out the "Image" and "Image Markup"...)

- For now, Images should be unique to an Article, but down the road, maybe I'll want to use one Image across multiple Articles?

- The Article Image is actually used in at least two place for a given Article... a.) In the "Article Summary" (page), b.) In the "Article" (page)

- The Image Size in the "Article Summary" and "Article Body" will vary. (One is full-sized, and the other is a reduced size.)

-------

I am wondering if it would make more sense to do this...

- Keep the Image File in the "images" directory.

- Create an "image" table and store the:
- name
- width_main
- width_summary
- alt
- title

- When I build my "Article Summary" page, query the "article" table and dynamically build the HTML for the Image.

- When I build my "Article" page, query the "article" table and dynamically build the HTML for the Image.


Possible Pros:
- Image Info stored in *one* place
- Image Info easier to update since it is database fields


Possible Cons:
- Extra overhead to build an Article
- Slower page loads


So what do you think about all of this?

Thanks,


Debbie

[Cups]

Cons of not doing what you plan:

If you change an image title you have to alter all the corresponding text in the articles.
If you change the way an image is displayed you have to alter all the corresponding text in the articles.
You cannot easily find out how often an image is displayed.
You cannot easily find out which images are not being used.

If articles to images could possibly become 1:n (ie one article could contain 1 or more images) then your db structure should resemble:

articles
=====
id | 23
name | My Article about Goats
....etc

images
=====
id | 99
title | Goat
alt | A goat
path | goat.png

article_image
==========
article_ref | 23 
image_re | 99

Where the two fields in article_image are declared with a UNIQUE index to make sure you don't have duplicates.

That leaves the door open to have another row in article_image

article_image
==========
article_ref | 23 
image_re | 1001

So now you can have 2 images for this article id 23.

So to retrieve the images associated with an article you JOIN images to article_image WHERE article_ref = 23

Try some of these links to teach yourself about database normalization with examples of tables. You will find it easy enough to grasp.

[DoubleDee]

Cons of not doing what you plan:

If you change an image title you have to alter all the corresponding text in the articles.
If you change the way an image is displayed you have to alter all the corresponding text in the articles.
You cannot easily find out how often an image is displayed.
You cannot easily find out which images are not being used.

Cups,

Thanks for the response!

You make some very valid points, however, I'm not sure I did a good job describing the larger issue here... (Actually, there are 4 questions I have on this topic...)

Off Topic:

BTW, I thoroughly understand Database Normalization, but my questions relate more to how to store the data separately and then merge it back together for display. And for this version of my website, I an NOT ready to jump into OOP or MVC, which may be part of the reason this question is so confusing to me...

Let me step back and try to explain things again...


Issue #1:
How much overhead am I adding to my Web Pages (and Website) by having to query one or more Images for *every* Article (versus just hard-coding them)?

If my website becomes wildly popular, will I be crying in 6 months because while this decision "normalized" things more, it also has brought my website to a grinding halt?!



Issue #2:
Currently I have the same information in 2 fields in the Article table... (What I described in my original post.)

Obviously this wasn't such a great job, but it served its purpose for my first go-round?!

image field (Used for "Article Summary")

<img class="noborder" src="/images/PostageMeter.png" width="150" alt="Picture: Postage Meter.  Credit: John Doe, Wikimedia Commons." title="Picture: Postage Meter.  Credit: John Doe, Wikimedia Commons." />

body field (Used to create the "Article")

<img class="noborder" src="/images/PostageMeter.png" width="150"
alt="Picture: Postage Meter.  Credit: John Doe, Wikimedia Commons."
title="Picture: Postage Meter.  Credit: John Doe, Wikimedia Commons." />

<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus suscipit mattis laoreet. Quisque convallis elementum scelerisque. Nullam accumsan, purus in condimentum placerat, eros lorem pellentesque justo, eget ullamcorper purus felis et magna. Mauris blandit feugiat semper.</p>

<h3>Time is Money!</h3>
<p>Proin viverra vestibulum velit quis dapibus. Maecenas mattis mauris id eros mollis nec venenatis est faucibus. Maecenas fringilla eleifend tellus, vitae gravida purus rutrum non.</p>

Issue #3:
If I broke out the Article Image to another table and created a many-to-many, I understand how to create a function that queries the data and builds the Image HTML for my "Article Summary".

However, this isn't so easy for the "Article Body", because I have the *single* Article Image embedded in the "body" field.

I would need a way to query the Article Info, then build the Article HTML, and then merge into the existing Article HTML.

Like shown above, an Article currently looks like this...

<img class="noborder" src="/images/PostageMeter.png" width="150"
alt="Picture: Postage Meter.  Credit: John Doe, Wikimedia Commons."
title="Picture: Postage Meter.  Credit: John Doe, Wikimedia Commons." />

<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus suscipit mattis laoreet. Quisque convallis elementum scelerisque. Nullam accumsan, purus in condimentum placerat, eros lorem pellentesque justo, eget ullamcorper purus felis et magna. Mauris blandit feugiat semper.</p>

and so on...

Maybe I could use something like was recommended in my other thread Trying to store PHP in MySQL?



Issue #4:
The "Article Image" that I have been talking about is the main Image for an Article, and - if one exists - would be used in the "Article Summary" and "Article Body".

However, down the road it is my goals to have several Images in each Article, so that things read like a magazine article (e.g. Time, Newsweek, etc.)

With that being said, I again understand how to break things up in my database (i.e. many-to-many), however, I do NOT understand how put things back together in the Article.

Off Topic:

BTW, I explicitly decided to place my marked up Article into MySQL, because there is no way to create a "template" for the mark up. Each Article is unique, and needs a "human touch" with me deciding how I want the layout and semantics to come together!!

It is easy to have my Text/HTML in MySQL.

Where it gets complicated, is how would I store the "Article" and the "Images" in separate places and then "build" the finished product?!

Again, maybe the link to the thread above could be modified to make things work, but since the # of Images will vary from 0 to 1 to many in each Article, I am not sure how to apply the logic I used for One Image to Many Images in One Article?!

Hope all of that makes sense?!

Thanks,


Debbie

[Cups]

Your images, and their associated meta-data should be separate entities in my book - that way they are easier to manage.

You are presently bundling all this "knowledge", or data, and meta data as plain and simple text thus rendering it inert.

That is a bad design decision, architecturally speaking.

As things are, OK its pre-formatted, and you say that suits you because you can move things around in your text and totally customize each and every page.

If that is your criteria, then stay as you are, but honestly you might as well be editing the html using Frontpage.

This "page building" will likely be achieved using one or more JOINS which may not even involve another database request.

Your concern about using more db requests for fear of stopping your server is misguided. This is what the LAMP stack is designed to do.

If or when you decide that your server really cannot take any more, then you start looking at using caching -- where you "bake" a version of your html (or part of it) and store it as a html file on the hdd ready to be served up with no further processing.

This is what I currently do on some pages which I deem to be more or less static, I overwrite the cached file if the db record is ever edited.

It seems to me your current set up is actually holding a cache of the guts of your page at the moment, so you have in fact got the worst of both worlds.

You cannot access the data that drives your site, and your caching strategy is to hit the database.

Now, all the above is fine and good if you just want images appearing in the same place on the webpage, or if you want to drive a slide show.

However, this isn't so easy for the "Article Body", because I have the *single* Article Image embedded in the "body" field.

So, how are the images being "embedded" into the body of the article? How do you currently achieve that?

If the only person doing this authoring is you, then you can do what you like.

<p>some text</p>
<?php getImage(1001, "Customized ALT text for a goat is here"); ?>
<p>some more text</p>

[DoubleDee]

Your images, and their associated meta-data should be separate entities in my book - that way they are easier to manage.

And that is why I started this thread, because I am coming to the same conclusion.

You are presently bundling all this "knowledge", or data, and meta data as plain and simple text thus rendering it inert.

That is a bad design decision, architecturally speaking.

I agree.

As things are, OK its pre-formatted, and you say that suits you because you can move things around in your text and totally customize each and every page.

If that is your criteria, then stay as you are, but honestly you might as well be editing the html using Frontpage.

I don't think you are following me...

I want every Article to be "semantically" correct, and thus marked up using proper HTML that would make the SitePoint HTML/CSS Forums proud of me!!

So that means wrapping everything in proper HTML tags like <h2>, <p>, <br />, <li>, and so on. (I don't want to upload an Article in a web form and have the browser insert New Line (\n) characters where there should be something like a <p> or <br />.)

I am sure I could write some complex program to take my Article and convert it to "proper" HTML, but considering the CRAP that most WYSIWYG Editors produce, that is hard to fathom!! As such, it is MUCH EASIER to compose things in OpenOffice, then paste it into NetBeans, and add my own HTML tags as I see fit...

To me, that shouldn't be seen as "strange" or "radical", although I'm sure some see that process as crazy...

Your concern about using more db requests for fear of stopping your server is misguided. This is what the LAMP stack is designed to do.

Just being sure...

If or when you decide that your server really cannot take any more, then you start looking at using caching -- where you "bake" a version of your html (or part of it) and store it as a html file on the hdd ready to be served up with no further processing.

On a side note, so if I have a Web Page with the following components...

- Header with User's First Name, # of New Messages, # of Friend Requests
- Left Nav with Upcoming Conferences
- Center Area with Listing of Articles

...and I used 3 separate SELECTs for the Header, 1 SELECT for the Left Nav, and 1 SELECT for the Center Area, then that wouldn't be bad?

It seems to me your current set up is actually holding a cache of the guts of your page at the moment, so you have in fact got the worst of both worlds.

You lost me.

Now, all the above is fine and good if you just want images appearing in the same place on the webpage, or if you want to drive a slide show.

Again, what I am trying to say is that every Article will have a slightly different layout. For example, Article #1 might start off with an Image followed by Text that floats around it. Article #2 might have No Images. Article #3 might have 3 Images, plus a Graph, and an Illustration.

In each Article, the Text, Paragraphs, and Image Layout would vary.

As such, you couldn't easily write a script to take my uploaded Article and create the HTML I really want. (That is why I like doing things manually.)

So, how are the images being "embedded" into the body of the article? How do you currently achieve that?

Step #1: I would write the Article in OpenOffice...

Time is Money!

When Office Managers are looking for places to save money, postage probably isn't the first thing that comes to mind. However, just a few trips per week to the Post Office can cost your small-business more in lost productivity and money than you think!


More Affordable than Appears

A lot of people would guess that owning a Postage Meter is expensive but that isn't the case. First of all, you normally would lease one from the Post Office...

Step #2a: I would mark it up manually in NetBeans...

<h2>Time is Money!</h2>

<p>When Office Managers are looking for places to save money, postage probably isn't the first thing that comes to mind.  However, just a few trips per week to the Post Office can cost your small-business more in lost productivity and money than you think!</p>


<h2>More Affordable than Appears</h2>

<p>A lot of people would guess that owning a Postage Meter is expensive but that isn't the case.  First of all, you normally would lease one from the Post Office...</p>

Step #2b: I would add in the HTML for an Images...

<img class="noborder" src="/images/PostageMeter.png" width="150"
alt="Picture: Postage Meter.  Credit: John Doe, Wikimedia Commons."
title="Picture: Postage Meter.  Credit: John Doe, Wikimedia Commons." />

<h2>Time is Money!</h2>

<p>When Office Managers are looking for places to save money, postage probably isn't the first thing that comes to mind.  However, just a few trips per week to the Post Office can cost your small-business more in lost productivity and money than you think!</p>


<h2>More Affordable than Appears</h2>

<p>A lot of people would guess that owning a Postage Meter is expensive but that isn't the case.  First of all, you normally would lease one from the Post Office...</p>

Step #3: I would paste it into the "body" field of my "article" table using phpMyAdmin.

(So the Image is "embedded" in my HTML which is stored in MySQL. Follow me?!)

If the only person doing this authoring is you, then you can do what you like.

<p>some text</p>
<?php getImage(1001, "Customized ALT text for a goat is here"); ?>
<p>some more text</p>

But my Article is stored in MySQL, so how would your example above help me out? You certainly aren't implying I copy everything above (i.e. HTML and PHP) and stick it in my "body" field, are you?


BTW, were you able to check out the other thread I mentioned?

Maybe I can modify that approach, so that I replace an "Image Placeholders" with "Image HTML"?

Thanks,



Debbie

[kduv]

As far as building your HTML to include images from another table, you could just use placeholders for the images then do something simple like so ...

$body = "
{{IMG imagename}}

<p>some html</p>
";

$body = str_replace("{{IMG imagename}}", '<img src="imagename.jpg" />', $body); 

Of course there are many ways to do it, but that's the general idea.

[DoubleDee]

A quick note before I head off to supper...

I am thinking this snippet of code might help me address the problems I face above...

<?php
    // Initialize array.
    $matches = array();

    $body = '<h3>Time is Money!</h3>
            <p>Proin viverra vestibulum velit quis dapibus.
            Maecenas mattis mauris id eros mollis nec venenatis est faucibus.
            {img=Butterfly.png} Maecenas fringilla eleifend tellus,
            vitae gravida purus rutrum non.</p>

            <h3>More Affordable than Appears</h3>
            <p>Vivamus facilisis diam eget nunc ultrices vitae venenatis
            lorem laoreet. Phasellus aliquet condimentum diam vel feugiat.
            Quisque dapibus dictum felis, dapibus vestibulum arcu fermentum a.
            Praesent fringilla sem vitae velit cursus porta. {img=Flower.jpeg}
            Praesent vitae magna et mi volutpat ultrices a consequat odio.
            {123}</p>';

    // Find all Images in Article.
    if (preg_match_all('~\\{img=([a-zA-Z0-9-]+[.png|.jpg|.jpeg|.gif]+)\\}~', $body, $matches, PREG_SET_ORDER)){
        // Cross-Links Found.

        // Loop through array.
        foreach ($matches as $match){
            echo '<p>$match[0] = ' . $match[0] . '</p>';
            echo '<p>$match[1] = ' . $match[1] . '</p>';
        }
    }
?>

When I run this code, I get these results...

$match[0] = {img=Butterfly.png}

$match[1] = Butterfly.png

$match[0] = {img=Flower.jpeg}

$match[1] = Flower.jpeg

BTW, I totally need help with my Regex here, but when I ran this, it seems to be working for now?!

Need food!

Back when I can...

Thanks all!


Debbie

[cpradio]

A quick note before I head off to supper...

I am thinking this snippet of code might help me address the problems I face above...

<?php
    // Initialize array.
    $matches = array();

    $body = '<h3>Time is Money!</h3>
            <p>Proin viverra vestibulum velit quis dapibus.
            Maecenas mattis mauris id eros mollis nec venenatis est faucibus.
            {img=Butterfly.png} Maecenas fringilla eleifend tellus,
            vitae gravida purus rutrum non.</p>

            <h3>More Affordable than Appears</h3>
            <p>Vivamus facilisis diam eget nunc ultrices vitae venenatis
            lorem laoreet. Phasellus aliquet condimentum diam vel feugiat.
            Quisque dapibus dictum felis, dapibus vestibulum arcu fermentum a.
            Praesent fringilla sem vitae velit cursus porta. {img=Flower.jpeg}
            Praesent vitae magna et mi volutpat ultrices a consequat odio.
            {123}</p>';

    // Find all Images in Article.
    if (preg_match_all('~\\{img=([a-zA-Z0-9-]+[.png|.jpg|.jpeg|.gif]+)\\}~', $body, $matches, PREG_SET_ORDER)){
        // Cross-Links Found.

        // Loop through array.
        foreach ($matches as $match){
            echo '<p>$match[0] = ' . $match[0] . '</p>';
            echo '<p>$match[1] = ' . $match[1] . '</p>';
        }
    }
?>

When I run this code, I get these results...

$match[0] = {img=Butterfly.png}

$match[1] = Butterfly.png

$match[0] = {img=Flower.jpeg}

$match[1] = Flower.jpeg

BTW, I totally need help with my Regex here, but when I ran this, it seems to be working for now?!

Need food!

Back when I can...

Thanks all!


Debbie

Did you just alter my URL regex to work for images? Yes, Yes you did!

As things are, OK its pre-formatted, and you say that suits you because you can move things around in your text and totally customize each and every page.

If that is your criteria, then stay as you are, but honestly you might as well be editing the html using Frontpage.

I don't think you are following me...

I want every Article to be "semantically" correct, and thus marked up using proper HTML that would make the SitePoint HTML/CSS Forums proud of me!!

So that means wrapping everything in proper HTML tags like <h2>, <p>, <br />, <li>, and so on. (I don't want to upload an Article in a web form and have the browser insert New Line (\n) characters where there should be something like a <p> or <br />.)

I am sure I could write some complex program to take my Article and convert it to "proper" HTML, but considering the CRAP that most WYSIWYG Editors produce, that is hard to fathom!! As such, it is MUCH EASIER to compose things in OpenOffice, then paste it into NetBeans, and add my own HTML tags as I see fit...

To me, that shouldn't be seen as "strange" or "radical", although I'm sure some see that process as crazy...

Now for a serious note. You focused on the wrong aspect of @Cups ; suggestion. Forget about the tool used to create the files, but rather think of the approach he is suggesting. He is stating why not just create a physical file that can be loaded and forget about MySQL.

Consider the following file structure
/ - root
/images/ - where your images are stored
/content/ - where your full articles are stored as an HTML file (one per article)
/content/summary/ - where you summary of each article is stored as an HTML file (one per article)

You would have an index.php page in your root folder that would load your design and process any Rewrite Rules (loading the home page, the article summary, or the full article). That would then load the appropriate file in the /content/ folder or the /content/summary/ folder using include() or require().

This removes MySQL entirely, allows you to write the HTML as you want (so each article can still be displayed in a different manner). The only drawback is if you were to change an image, or want to change the alt/title, etc. As you would need to use Find/Replace to do it, or manually change the files. That might be okay for you, that may not be a big deal at all and this becomes a very feasible solution that requires no database.

@Cups ;, I hope I ran with the intent you were implying.

[Cups]

In a way yes, I was implying that could be an option.

I woke up this morning recalling how I ran a site where all the (what I deemed) "static content" was simply html, and yes, I used Frontpage to mark that up.

Each page started off with the lines:

<?php 
$pageId = 123;
include 'header.asp' ;
?>

<!-- Static html was here, from main div page on down to the start of sidebars, footers etc -->

<?php include 'footer.asp' ; ?>

The pageID was the key to get all the meta data the page needed to build up its menus, sidebars, owner etc.

Naturally there was a lot of db driven data in other pages, but in order to be able to break free of the constraints of a cms and to be able to provide the sometimes incredibly complex html solutions that users demanded, I used this system (for years).

There is no reason why you cannot run a template driven cms along with a semi static system like this.