Hey guys, I'm a bit of a PHP noob, so will try my best to describe what I'm trying to do...

I am working on a front-end 'news upload' system which will allow any members of my organisation to upload news items to our news database using an HTML form.

I have coded as far as when it comes to generating the stand-alone pages for news items themselves. I have the data in the fields in the database outputting onto our homepage as desired but would also like to generate a new PHP page for each item that is uploaded as well, but I am unsure as to how to go about this.

Basically, at the same time that the homepage is being updated (immediately after writing the data to the database) I would like to generate a stand-alone .php file in it's own directory, say 'news'. I hope this makes sense?

Any advice as to how I would go about doing this would be much appreciated.

    That kind of takes away much of the point of using a database, why would you want static pages as well as dynamic?

      rincewind456;10930114 wrote:

      That kind of takes away much of the point of using a database, why would you want static pages as well as dynamic?

      Thanks for the reply. I have now realised that I don't want to create static pages for each, not sure why I was under such an illusion.

      So essentially I will need a template page for news items which is generated dynamically with the relevant news info dependent on say, the primary key of my DB?

      Is it as easy as this?

        It is 🙂

        But what you identify your db news item by depends on circumstance. If the user clicks a link to read a news item, then the primary key is an obvious choice. But you might also want to select news item(s) based on publish date, category etc.

          johanafm;10930174 wrote:

          It is 🙂

          But what you identify your db news item by depends on circumstance. If the user clicks a link to read a news item, then the primary key is an obvious choice. But you might also want to select news item(s) based on publish date, category etc.

          Excellent, I think at least initially the ID of the item will be enough, though having categories is something we are likely to look at.

          To touch on the date issue, we currently have a manual 'news archive' which we would like to be generated dynamically also. Is selecting news items based on publish date as you say more efficient than just listing items in descending order of ID for each month? I currently have a date field in format (Y-m-d).

            Huskie;10930194 wrote:

            Is selecting news items based on publish date as you say more efficient than just listing items in descending order of ID for each month? I currently have a date field in format (Y-m-d).

            Assuming both the id and publish date are indexed (primary key always is, for other things you need to add this where you want it), they should be equally efficient.

            If your CMS does not allow users to specify publish dates, then you might just as well go with id in descending order. But if you do allow it, things will not be in chronological order this way since I could write an article, set publish date to next week, then write a new article and publish it right away...

              johanafm;10930200 wrote:

              Assuming both the id and publish date are indexed (primary key always is, for other things you need to add this where you want it), they should be equally efficient.

              If your CMS does not allow users to specify publish dates, then you might just as well go with id in descending order. But if you do allow it, things will not be in chronological order this way since I could write an article, set publish date to next week, then write a new article and publish it right away...

              At the minute, the users don't specify a publish date. I think we will stick to this approach as we have no real need to hold back on publishing of items so I will try using the id only for the purpose of archiving.

              Another question, is there an easy way to offer users a chance to 'preview' what they are about to upload? This isn't essential but would be handy to at least initially until they are familiar with the process.

                You could use a WYSIWYG editor such as TinyMCE. Still, to show a preview that is certain to be exactly the same as the end result, you'd still need to post to the server, run the content through your filters and present filtered output back to the user.
                You can let the same script handle both this and actual storing of info in the db. The only difference is that you don't store it, but somehow just echo it back to screen. Or, you keep a status field for each entry containing, 'draft' or 'published'.

                  johanafm;10930205 wrote:

                  You could use a WYSIWYG editor such as TinyMCE. Still, to show a preview that is certain to be exactly the same as the end result, you'd still need to post to the server, run the content through your filters and present filtered output back to the user.
                  You can let the same script handle both this and actual storing of info in the db. The only difference is that you don't store it, but somehow just echo it back to screen. Or, you keep a status field for each entry containing, 'draft' or 'published'.

                  I may look into using a status field for the entries as I don't want to get tied down to implementing something too time-consuming given my current experience of PHP and considering that only a handful of people will be using the system. Thanks for answering all my questions!

                    Write a Reply...