Jump to content

$first_topic = "hello all freaks"; (noob says hi! and asks...)


Recommended Posts

Hi to everyone at phpfreaks!

 

My name is Mike and I live in Oxfordshire in the UK, am neare 50 than 40 and love riding my KTM 950 Supermoto!

 

I'm looking forward to getting involved here and maybe even helping others when and if I can...

 

 

Am using Dreamweaver 8 together with some php and now phpmyadmin and MySQL via webfusion ISP

 

I'm self taught in dw8 and learning php/myadmin and MySQL stuff from scratch..."my mind is going - I can feel it!!!"

 

I've run a static site for a year and a bit now selling antiques and the like (see www.vintage-home.co.uk).  I like trying to do things myself and not just buying a 'site-in-a-box' kinda thing.

 

Bear with me - there's not too much more of this...

 

With around 300 static product pages I think it's now time to introduce my first simple database.  I intend initially to keep the 'framework' of static pages but replace the core 250-300 static product pages with one master php page linked to a database.

 

I've setup a local test server with the help of 'Easy PHP' and created some sample pages that are linked to the database with recordsets, bindings and the like - my pages are 'working' fine, getting and displaying stuff from the DB, using variables, IF's and the like and with variables passed via URL etc.

 

Even at this early stage - I'd like to know something about keeping my database secure and hack-free (once I go live with this stuff) and how to enable folks bookmark (add to favourties) my dynamic pages?...

 

I've tried a search or two here at freaks - but I'm not sure which keywords would best return what I'm looking for at this stage.

 

Initially, the database will just supply bulk fill to the main display page - a single table with no customer input...I know I could do so much more but I'm doing this one step at a time. :-*

 

I'm sure that's more than enough for now - and I'm sorry if this is in the wrong part of the forum  ???

 

Kind regards and thank you in advance for any assistance rendered...

 

"...open the bomb-bay doors HAL..."

 

mikey_b

 

If your are in a hurry,

 

Use PEAR, SMARTY, Joomla, Mambo, etc

Available PHP packages...

 

I understand exactly what situation you're in.

If you want to start your own CMS(I always do my own stuff and asl for help), I can help you and actually give you resources (even a complete antique selling site I made before though not exactly what you need but a great).

 

A good solution might require huge postings here.

I will message you my email, tat's of course if you are interested.

Hi gnawz!

 

Thanks for the reply...

 

At this point, and in a nutshell, I suppose I'm asking:

 

a) What level of security do I need for my single table database - for which there will be no user input a this stage?  Is it enought that the database is password protected or do I need to protect against other stuff?

 

b) What do I need to do to allow folk to bookmark (add to favourites) my dymanically generated pages?  Google and other sources suggest that if you're only using 1 or two variables passed in a URL query string then there's no need to bother?  But I saved one of my dymanically generated pages to 'favourites' and then closed the browser - opened it back up and clicked on the link only to end up having to dump out of IE7 'cus it couldn't load the page...mind you this is all happening with a local test site - it's not on my remote server as of yet...

 

Cheers

 

more soon

 

Mike

a) You should not have a single table in a database.  You need to separate various parts of the data model into different tables.  Read up on database normalization.

 

b) You're probably doing something wrong; we'd need to see what your code looks like.

Hi Darkwater,

 

Thank you for your reply...much appreciated.

 

The second point (b) is now mute - after I uploaded the database to the remote server and got everything 'talking' - the bookmarking/favourites issue is gone - bookmarks all work fine on all browsers etc. So thanks for listening to my woes on that.

 

Regarding the point of normalizing my database - having read your comments I went and had a quick review of the basics. Strangely, amongst the hundreds of antiques we have for sale - no two are very much alike. I mean they look different, are made by different folk over time, from different places and eras. You can't really categorise them by colour or style - it's a real can o' worms... All the fields(?) in each record(?) in my sample single table database appear uniquely dependant to the primary key (the product code) though I suppose there are some generalities such as the number of photos for each and the general category they fall into (bedroom, kitchen, paintings etc.) so maybe this is where they could be normalised?

 

I'm trying to take this gently, teaching myself everything one step at a time,  and creating multiple tables seems a little daunting - but I take your point seriously and will read up on this further.

 

Kind regards

 

Mike

 

Mike,

 

Without knowing your dataset, I would say you should try to think about how your clients would want to browse the data.

 

-When someone goes to their site, do they spend time browsing all 200+ pages of antiques, or do they search for something they want?

-Can they be broken down like you said to categories: "For the Home","For Outside","For the Bedroom", or multiple "For the Bedroom" & "For the Kitchen".

-Are they made of similar materials: wooden, bronze, gold, steel?

-What era? 1900-1910, 1911-1920, etc?

-Price range [not necessarily a database technique, but a php generated category]

-Size based: Trinkets, Small, Medium, Large

 

All these things are different ways to consider categorizing your data.  There is no "right" answer per say, but it's more a choice of functionality and ease of use.  How can you best chunk your data so that it's more agreeable to be viewed?  You could use any or none of the options listed above, but they are just examples.

Cheers Xtopolis,

 

It's so refreshing to just have other points of view - thank you.

 

What you and others have said is good reading and is making me think.

 

At the moment, folks come to the site and choose a 'type' of product (e.g. pottery, paintings etc.) and then browse that section. I've used jump menus to enable them to cross-over to any other section at will and (displaying items initially 6 to a page) a page selection option along the bottom of the page.

 

Learning this as I go (eek!), two things that put me off getting too flash were:

 

1.) I read everywhere that search bots don't like your whole site to be dynamic - I presumed that currently my 300 static pages (a few dozen of which change every month as stuff is sold) did at least give good SEO as they all full of interesting related text and images blah blah blah...

 

I think that having seen the bookmarks think work fine and also reading that google and other bots can handle url query strings provided they aren't too complex -has given me a little more confidence to use the database not only for a single product display page - but across the site for selection pages, search pages and the like.

 

2.) I didn't want to over-egg the pudding. I only have 250-300 products and thought that this didn't warrant having numerous fancy table structures all wizzing back and forth trying to be clever...[smile] Currently the database will have some 300 'items' within it - each with 25 fields - of which 20 are boolean (? - just a y/n value). The others are price, product name, a unique item code and then the two largest which are a both text descriptions of the item in question (a paragraph or so each).

 

I'm quite excited by the idea of creating a relational database (I know, sad isn't it!) but didn't want to do it just because I could or if the project didn't warrant it...

 

I suppose using a relational database I could offer folk the choice of selecting via colour, era, value etc. rather than just 'kitchenalia, bedding, paintings' etc. - but I'm not sure that's not just offering the same choice I am now but via a different set of words?...

 

Anyway, as you say, I need to learn lots, to give it some thought - meanwhile I'll keep knibbling away at it...

 

I'll always appreciate any comments and advise...and I don't want to ever sound like I'm questioning the knowledge and experience you all have - I'm just letting you know how the noob mind works! [smile]

 

Mike

1) Unfortunately I don't know much about SEO as design private sites and backend stuff.  So I can't help you there.

 

2)Databases come into play by their ability to change multiple(correct designed) sets of things easily.  Like I said, it's hard to know how your stuff works.. it seems like you have central includes for menus, and manually append pages to type "ie Kitchen.."..

 

Also, you have 300~ unique pages.. when you could have 1, or less than 10.  Now, this might not be good for SEO.  I don't know.  But you could have 1 per theme( pottery, paintings ) branded for looks and have it pull the item information out of the database and fill in the new info on the same page.  This would be handy for any design changes.

 

It also makes it easy to start seeing patterns and groupings.  Right now since I'm thinking all your prices are hardcoded per page, it would be slightly difficult or time consuming to get a list of say "all items costing between 25$ and 50$" or "pottery items that are less than $30" etc etc..  things you could introduce easily onto your page to further try to attract attention to 'deals' your clients weren't aware of.

--sidebar-- Say a client clicks a pottery item cost $50+ dollars, you could have a side bar advertising a few random items of pottery costing $39 ish dollars, or even others in the $50 price range.  You can suggest things that your customer might like, etc.

 

Lastly on this point.  Databases reflect your ability to change.  Say perhaps you do well enough someday soon and you want to buyout another antique shop.. say they have 400 items.  That's a lot of copy pasting with your current system to introduce 400 unique items.  Well if you had a database, you could enter in just the data about them (type, price, etc etc) and have them automatically available in your dynamic pages.  You might think you would never succeed like that.. but just thinking you won't is bad for business! :P

 

Perhaps read this database tutorial: http://www.phpfreaks.com/tutorial/data-joins-unions

It might be a little over your head, but it could help you understand the power of having normalized data in your database and how easy it is too pull different groupings/info from it.

 

And I guess a final note:

If it's not broke, don't fix it.  You have something that works[well I'm assuming], so it may not warrant any of this at all.  However I was under the impression you wanted to try something new, might as well go big!  You can always remove features if you don't want them.  And besides you'll still have a working system while having fun trying a new one.

I read everywhere that search bots don't like your whole site to be dynamic - I presumed that currently my 300 static pages (a few dozen of which change every month as stuff is sold) did at least give good SEO as they all full of interesting related text and images blah blah blah...

 

You can use mod rewrites / htaccess files to make dynamic URLs look far more SEO-friendly. Also, just watch out for duplicate content.

Thanks for the replies once again folks!

 

It's all going 'in' and hopefully some of it will stick  :D

 

I am scanning new questions from others just in case I can help - you never know...

 

The two questions I asked have been answered - so thank you.

 

Don't worry, there'll be others - there always are!

 

Kind Regards

 

Mike

  • 3 weeks later...
This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.