I'm working on a website I eventually plan on purchasing a domain for and having, hopefully, many users. Of course, a lot of people plan on that and it never comes true! Regardless, I'm progressing forward with the intent of having a good looking interface that's efficient in it's data usage.
One thing I would very much like to do is to have my banner / header and side-bars persist when they navigate to separate pages inside my site. My header contains the site-wide context menu as well as login and profile information, and the side-bars are currently undecided, but potentially just static images.
I don't know exactly how I would do it well. I could just use my PHP session object, but I'd like to be as efficient as possible.
I'm using a traditional LAMP stack, HTML, JS and CSS (using the Bootstrap library) on Ubuntu on an Amazon's EC2 service.
You could create a file with header and sidebar and then use this php code:
include("nameofthefile.php");
on every file of your site
Related
I am currently designing a website for a business. This website will have dynamic areas - such as an "admin" area in the future. But for now, there are going to be 14-16 static pages. Testimonials, products and services, typical corporate pages.
I really like the idea of loading html dynamically with backbone and doT.js. But for this purpose, am I better-served with a multiple-page approach? I've read that single-page designs can harm SEO but wasn't sure if that was still accurate. That is of major consideration for a basically fully static site where content is king.
Is SO a single-page site?
I am using apache2 with PHP/symfony2 for my current multi-page implementation for all of the static pages (and caching them).
It sounds like your site would be better off as static as possible. There's a lot of upside:
It should load quickly, because there's no processing to do, fewer files to load, and once it's sent to the browser you don't have to wait for the JavaScript to run before the page shows.
It will be more widely supported. Everything supports HTML; if your page loads require JavaScript, you might be cutting people off and never realise it.
Search engines will have a much easier time indexing static sites.
It's easier to develop and maintain a simple static site.
It's a lot harder to break. If your page loads require JavaScript and you accidentally deploy a broken script, you run the risk of completely blank pages. In a static site, chances are the text will still show.
Things like Backbone and JS templating are great when you're dealing with dynamic data. Backbone comes in to its own when you have objects that you're showing on a page, and want to build a complex interface to interact with them. But that doesn't sound like your page here. Similarly, JS templating is great if you're sending data to the page, maybe from an AJAX request, and want to render it client-side. But it doesn't sound like that's the case for this project.
In general, try to do the simplest thing that will work. Building the site as a static page will be a good starting point, and if you want to add JavaScript to it later you can build on that foundation.
I am currently trying to figure out a way to create templates for a number of pages that look exactly the same. The only thing that is different is the content part.
I have worked with PHP and include() to separate several parts of my pages, but still need something that allows me to set a default layout and styling of an entire page since I will be creating thousands of pages that are identical.
Please help me with some tips! Highly appreciated.
thousands of pages that are identical.
As stated in the comments, you should definitely go with a CMS (Content Management System)
Main features of a CMS:
Allow for a large number of people to share and contribute to stored data
Control access to data based on user role (i.e., define information users or user groups can view, edit, publish, etc.);
Facilitates storage and retrieval of data;
Control data validity and compliance;
Reduces duplicate inputs;
Simplify report writing;
Improve communication among users.
Define data as almost anything: documents, movies, texts, pictures, phone numbers, articles etc.
Content Management of Pages
Reference: http://en.wikipedia.org/wiki/Content_management_system
With that said, unless you want to spend countless hours studying and learning (which is not a bad thing) but it seems that you simply want to get this sophisticated website working, then a CMS is what you really need.
Take a look at what i believe are the top CMS's out there:
Joomla
Wordpress
Dupral
In a nutshell, you just need to get your Host, http://www.godaddy.com/ (not my personal favorite) but for simplicity; godaddy will install the CMS for you with a click of a button, it will setup everything and get you up and running! After that is complete, you can login via the administrator panel and play around with the settings to see how things work.
I would start with WordPress, heres a nice site to get you going once you have everything setup (assuming you go for Wordpress CMS)
http://www.siteground.com/tutorials/wordpress/wordpress_start.htm
http://codex.wordpress.org/Site_Design_and_Layout
Have fun! Hope this helps.
I am curious if anyone can explain how does Cushy CMS implement its features. What I am referring to is adding a class in html , like <div class="cms-editable"></div> and automatically make that div editable and save contents to database. Do they use a parser and write the file? I do not think they save the data to the database.
Cushy is FTP-based, meaning it works directly on your file structure. When you view your website after logging into Cushy's website it is this website interface that pulls in the page you are editing on and inspects the places where the class file exists and makes this an editable item. It uses the FTP credentials you have entered to make the call via FTP protocol to pull in your website pages. It also parses the dom and checks for the class name "cms-editable" and makes this content editable through an HTML editor after some configuration steps after installation. When you make changes and save them, it directly modifies the content area that you defined as editable via FTP again. There are many tools in any server-side language to accomplish this for FTP protocol and DOM parsing.
The Good thing about Cushy CMS
It works for static websites so easily, a designer could set it up.
The Bad thing about Cushy CMS
Its terrible for dynamic websites as your clients are directly editing on your pages and will easily break the website with accidental syntax errors. It does not fit for MVC-style and web programming in general.
It requires too much administration after setup as you have to first set an item to be editable on your file directly, then you must give permission through its interface. Imagine doing this for a templated pages being reused. Basically you can't.
It cannot handle the same file being edited in different parts at the same time by different users because its actually just a source file being edited upon. Here is where overwrites become an issue when someone saves something thinking they are only saving the part they edited, not realizing they just saved the entire document.
To give background to my answer, I wrote a CMS tool that is cloud-based and built in a completely different manner than Cushy because its for developers as FTP is a huge limitation when a feed-based approach is much more appropriate. Also, having to log into another website to edit your stuff just sucks. In fact, why even have a back office at all when you have HTML5 client-side editing capabilities and postMessage for cross-domain communication? My profile has more details on this approach.
I have a small project about a dynamic database driven website which is users can post, comment, like,... on it.
and I was thinking about creating html pages instead of php pages.
for example after someone posts sth a php code will create a html page for that post and people can comment on it. while submitting a comment, an ajax call to a php page will save comment data to database and write that comment to the html file.
I thought it could be a good way to reduce server load. and have advantages for SEO.
Does this technique have a name? and Does it have any more advantages or disadvantages?
Thanks in advance
There's a flat-file blogging engine called Kure. It's an open-source project so feel free to check it out. "Flat file system" would be the closest thing to a name for this technique.
I have to agree with my SO colleagues here. Servers and even personal computers are, for the most part, more than capable to handling what you're describing using a real database. Blogging engines such as Wordpress, are incredibly powerful and flexible and will save you a lot of hassle down the line.
That said, if you insist in creating your own flat-file system... more power to you. Good luck.
Yes, it is a known technique for optimizing serving of relatively static pages. By 'relatively static' I mean "dynamic, but update rarely".
For example, Yandex (a search engine) uses this to serve its main page. It's pretty rich page, and it would require significant resources to generate it on each request.
Also, there is (at least, there was) a plugin for Wordpress that does this.
You can't use this technique if your pages update often (it will not worth it).
You can't use this technique if your pages are personalized (that is, if you can't serve the very same page to all your visitors).
I don't know any name for this technique. I know it's already been used for some big sites in the past but I'm not sure it's still used because it's not always easy to handle and if a file is corrupted because of a script, other scripts working with the page can make it even worse.
I've been trawling SO for a couple of hours tonight looking for some answers, but I've not found anything that really answers what I'm after. My apologies if it has, in fact, been answered already.
I'm designing a new website and I'm trying to decide on the architecture to use to serve the content. In the past, my websites have used PHP feeding data into Smarty templates.
However, recently at my work, I've been working on a Java web application where jQuery was used to retrieve the data from a RESTful API (which returned JSON), where HTML template pages were used as the base and javascript was used (utilising jQuery) to fill in the content.
My question:
The website I'm designing will be in PHP, but would it be better to construct (or use an existing) RESTful API or to continue on as I've done before feeding the data into Smarty templates?
Are there real benefits to one or the other, or does it just come down to developer preference/experience?
If it helps, the website will be for a church, where the content types will be CMS-like; news/announcements, wiki-like pages, and a limited type of social networking (for the minister to communicate with parishioners).
Short answer: It sounds like filling the content with JavaScript would not be useful in your case. Loading the data with JavaScript is adding a layer of complexity with minimal or no benefit (in your case). Take a look at CMSs and websites that have similar functionality to what you're doing. WordPress, Drupal, etc.
For an example of when it might be useful to load data with JavaScript, check out the tags section on this site. When you search for a tag it queries the server without reloading the page. However, the initial tag list is loaded during the initial page load without any JS.
Here are some cases where you might benefit from loading information with JS:
There is some data that will take longer to load. For example, you're getting data from a web service. Using the traditional method, you would need all the data you need for the page to be available before it can be displayed. If you loaded that data with JavaScript, the page could load and the slow data would appear when it returns. Realistically, you would probably just cache the data but this is just an example.
You will be getting more data as the user stays on the page. You might want to update the page without refreshing.
You want the user to be able to query more data without refreshing the page.
Your users have limited bandwidth (mobile).
This site has more guidelines: http://www.oracle.com/technetwork/articles/javase/index-137171.html