Another 'design' question.
(Technologies in use: PHP, MySQL)
I need to allow customers to customize the looks of their pages' headers. What is the best way to store such customized headers (say pieces of html closed in a div). Is storing them in database any good?
Or would it be better to store them in php files and include them to each page instead of default header?
Or perhaps allowing users to edit html is a very bad idea and I should use some other means for allowing them to customize their headers? (mostly they use it to put a logo + some additional information, sometimes animated gif with advert, sometimes just text... no rule).
Please advise.
Storing them on the local filesystem is the most performant and simpler one, so you may want to go with this one.
However this will not be as good once you have to scale on multiple servers. The better solution then is to use some kind of shared storage (the mysql database solution), and to eventually cache the templates somewhere.
Html in a database is bad practice it might brings encoding issues (not too hard to resolve but still, a pain in the a##).
what you should do is define the level of customization you want to achieve and create the php classes that will allow you to create such a customized header from your code.
You will then have to store in your DB the values needed to rebuild this header on the fly.
Related
I am running a blog which other visitors can post on. I want to allow certain HTML tags like headers, linebreaks or links. What is a good or best piece of plugin software I can use for this?
Additionally, is it best practise to save the raw data and then whitelist it when it is time for display in the blog. Or shall I whitelist the data before saving it to the database, so that it is saved clean?
The built in function strip_tags already has whitelist functionality that works quite nicely.
As for storage, it's a judgment call, but I recommend storing everything in its raw state and encoding for display only. It's only a concern if you think you may accidentally forget to strip/encode on display.
I'm setting up a website where visitors will be greeted by a splash screen where they will choose a color scheme for the actual website; based on their selection, the actual website will load with a different stylesheet. I gather this can be done by concatenating a flag to the URL, then reading the flagged URL on the next page to determine the stylesheet to be loaded (for example, to load the dark theme, the url would become http://www.mywebsite.com/index-dark; clicking the light theme link would make the URL http://www.mywebsite.com/index-light. Problem is, I don't know how to add a flag to a URL, or how to read this flag on a different page. I've tried Googling the issue, but have found little practical information. How can this be done?
EDIT: I'd like to avoid using two separate pages, as I'll have multiple themes; that would mean copying basically every HTML page in my root multiple times, taking up space. I like the idea of a concealed $_GET variable, though.
Without more information, I can only give some general advice.
So I'm going to assume that you are building a page in PHP, so you could have two different urls and use mod_rewrite to convert /index-dark to /index?style=dark but that's crappy.
What you probably want is to use a cookie or a session. Basically you check a cookie, or session value, for the theme setting and then pick the appropriate CSS file when you generate the page.
This has several advantages:
Doesn't require using url rewriting, an error prone endeavour at the best of times
Allows for persistent setting (if you use a cookie) and doesn't involve complicated urls.
Allows for adding more themes without changing mountains of code, just add the setting to theme selector and the new CSS file.
GET variables are generally only useful for specific data sent with that request, a bit like POST variables are mostly for forms and submitted data. If you want persistent settings, then a session/cookie is the best option.
The "flags" you're mentioning are probably actually $_GET variables that have been disguised using mod_rewrite. What you can do is edit your .htaccess file to add in rewrite rules that change, say, www.mywebsite.com/index.php?style=index-dark to www.mywebsite.com/index-dark (unfortunately I don't have experience in how exactly to do this; I just know that it can be done) and have your PHP catch $_GET['style'].
So, currently I'm organizing my blog based on filename: To create a post I enter the name of the file. As opposed to storing the post in the database, I store them in PHP files. So each time I create a post, A new row in the table is created with the filename and a unique ID. To reference the post (e.g. for comments) I get the name of the current file, then search the entries table for a matching file name. The post ID of the comment matches the ID of that post.
Obviously this isn't the standard way of organizing a blog, but I do it this way for a few reasons:
Clean URL's (even cleaner than mod_rewrite can provide from what I've read)
I always have a hard copy of the post on my machine
Easier to remember the URL of a specific post (kind of a part of clean URL's)
Now I know that the standard way would be storing each post in the database. I know how to do this, but the clean URL's is the main problem. So now to my questions:
Is there anything WRONG with the way I'm doing it now, or could any problems arise from it in the future?
Can the same level of clean URL's that I can get now be achieved with mod_rewrite? If so, links are appreciated
I will be hosting this on a web host. Do only certain web-hosts provide access to the necessary files for mod_rewrite, or is it generally standard on all web-hosts?
Thanks so much guys!
P.S. To be clear, I don't plan on using a blogging engine.
As cletus said, this is similar to Movable Type. There's nothing inherently wrong with storing your data in files.
One thing that comes to mind is: how much are you storing in the files? Just the post content, or does each PHP file contain a copy of the entire design of the page as opposed to using a base template? How difficult would it be to change the design later on? This may or may not be a problem.
What exactly are you looking for in terms of clean URLs? Rewrite rules are quite powerful and flexible. By using mod_rewrite in conjunction with a main PHP file that answers all requests, you can pretty much have any URL format you want, including user-friendly URLs without obscure ID numbers or even file extensions.
Edit:
Here is how it would work with mod_rewrite and a main PHP file that processes requests:
Web server passes all requests (e.g., /my-post-title) to, say, index.php
index.php parses the request path ("my-post-title")
Look up "my-post-title" in the database's "slug" or "friendly name" (whatever you want to call it) column and locates the appropriate row that way
Retrieve the post from the database
Apply a template to the post data
Return the completed page to the client
This is essentially how systems like Drupal and WordPress work.
Also, regarding how Movable Type works, it's been a while since I've used it so I might be wrong, but I believe it stores all posts in the database. When you hit the publish button, it generates plain HTML files by pulling post data from the database and inserting it into a template. This is incredibly efficient when your site is under heavy load - there are no scripts running when a visitor opens up your website, and the server can keep up with heavy visitation when it only needs to serve up static files.
So obviously you've got a lot of options when figuring out how your solution should work. The one you proposed sounds fine, though you might want to give careful consideration to how you'll maintain a large number of posts in individual files, particularly if you want to change the design of the entire site later on. You might want to consider a templating engine like Smarty, and just store post data (no layout tags) in your individual files, for instance. Or just use some basic include() statements in your post files to suck in headers, footers, nav menus, etc.
What you're describing is kind of like how Movable Type works. The issues you'll need to cover are:
Syndication: RSS/Atom;
Sitemap: for Google;
Commenting; and
Tagging and filtering content.
It's not unreasonable not to use a database. If I were to do that I'd be using a templating engine like Smarty that does a better job of caching the results than PHP will out of the box.
As an exercise in web design and development, I am building my website from the ground up, using PHP, MySQL, JavaScript and no frameworks. So far, I've been following a model-view-controller design. However, there is one hurdle that I am quickly approaching that I'm not sure how I'm going to solve, but I'm sure it's been addressed before with varying degrees of success.
On my website, I'm going to have a resume and an "about me" bio section. These probably won't be changing very often.
For my resume, I think that XML that can be rendered into HTML (or any other format) is the best option, and in that case, I could even build a "resume manager" using PHP that can edit the underlying XML. A resume also seems like it could be built on top of MySQL, as well, and generated into XML or HTML or whatever output format I choose.
However, I'm not sure how to store my about me/bio. My initial idea was a plain text document that can be read it, parsed, and the line breaks converted to paragraphs. However, I'm not sold on that being the best idea. My other idea was using MySQL, but I think that might be overkill for a single page. What I do know, however
What techniques have you used when storing text for a page that will not change very often? How did they work out for you - what problems or successes did you have?
Like McWafflestix said, use HTML, if you want to output HTML. Simplest case within PHP:
<?php
create_header_stuff();
include('static_about.html');
create_footer_stuff();
?>
and in static_about.html something like
<div id="about">
...
</div>
Cheers,
Just use a static page, if the information won't change very often. Just using static HTML gives you more control over the display format.
Generally treating infrequently changing information the same as frequently changing information works well if you add one other component: caching.
Whatever solution you decide on for the back end, store the output in a cache and then check to see if the data has changed. Version numbers or modified dates work well here. If it hasn't changed, just give the cached data. If it has changed then you rebuild the content, cache it and display.
As far as structure goes, I tend to use text blobs in a database if there is any risk that there will be more dynamic databases. XML is a great protocol for communicating between services and as an intermediate step, but I tend to use a database under all my projects because eventually I end up using it for other things anyway.
I have created css page called style.php and included this the top:
<?php header("Content-type: text/css"); ?>
Does this make you cringe. Is it a terrible idea? I am doing this because I have created a CMS that allows the admin to control colors on pages (so the style.php script queries the database and grabs the hex values).
Any thoughts?
It's not a bad idea (subject to the notes about caching + content-type), but think about the cost of firing up a PHP instance (mod_php) or passing the script to an already running php (fastcgi style). Do you really want that overhead?
You might be better off writing a "cached" version of your CSS page to a static file, and serving that (or if you need per-page flexibility, selecting which style sheet to include; I assume your main page is PHP already)
This is a fine solution, just make sure that you are serving up the appropriate headers. See my blogpost about a related topic (search for "The important headers are" to get to the right section).
One more thing:
With the caching you might get into the situation where the user changes the color she wants to see, but (because it is cached at the client), the page doesn't update. To invalidate the cache, append a ?=id at the end of the URL, where ID is a number that is stored for the user (for example in the session) and is incremented every time she changes the color scheme.
Example:
At first the user has a stylesheet of http://example.com/style.php?id=0
When she changes the colors, she will get the url of http://example.com/style.php?id=1 and so on.
Assuming you use appropriate caching, as I imagine the CMS-driven values will probably not change very often, there's no specific reason to avoid creating a CSS include on the fly.
This is not a bad idea. This is a creative idea with numerous benefits:
your users can define values w/o you needing to worry about security (parsing css is hard)
you can enforce a more visually consistent set of skins (some flexibility is better than total flexibility)
simple to code