By kdecapite on

I just installed Drupal for the first time last night and immediately have some questions. I searched around on the forums and between reading through posts and the online handbook I think I have an idea of how to accomplish my goals. I would like to "ask the experts" first, however.

I'm a PHP web developer who is tired of building custom content managers by hand for every website I create! However, I definitely don't like the tight integration between frontend and backend content that Drupal uses by default. Instead, I would like a separate website altogether that handles the backend/admin functionality. This is how I currently build my applications:

Frontend/Public website:
www.mywebsite.com

Backend/Admin website:
admin.mywebsite.com

I should point out that the "admin.mywebsite.com" actually sits within a separate web space on the server. In other words, it has it's own Apache virtual server entry and is NOT located within the root of the "www" domain. So in order to accomplish this setup with Drupal, it sounds like i would need to:

1. Install Drupal in my "www" web space
2. Customize my individual HTML pages to use the PHPTemplate (big learning curve here?)
3. Disable all login and admin functions for this Drupal installation
4. Install Drupal in my "admin" web space
5. Setup this installation according to the needs of the website
6. Make sure both installations are using the same database (set in the settings.php file)

Many thanks to anyone who can offer some suggestions, or at least confirm that this is a good (or perhaps bad) idea!

- Kevin

⋅ Categories: Drupal 4.7.x

Comments

gellpak’s picture

gellpak commented

This is almost exactly what I'm trying to do with a new site of my own... If you figure out specifically how to go about this, please post some info here about it and I'll help out where I can.

kdecapite’s picture

kdecapite commented

I'm hoping to implement this method of content management on a site I'm currently building. Here's the link to view progress if you're interested. It's currently just static HTML pages using my own "quick and dirty" templating scheme (just 2 PHP functions).

http://www.creationsitenetwork.com:8000/Hangar/www/

Username: hangar
Password: wharf

As I make progress I'll update the link. Thanks for reading...

- Kevin

sepeck’s picture

sepeck commented

There is no real seperation between 'admin' tasks. It is more, what rights does a user account have.
1. easy enough
2. Yes/no, depends.
3. Disablle the 'login' block in admin >> blocks. configure user registration
4. bad idea, hard to seperate out, not really designed for it. Designed to be integrated.
site/user (login) configure admin menu block to only be visible to specific UID# (User ID#)
5. depends on what you want to do and if existing modules help you accomplish it.
6. see answer to #4

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

kdecapite’s picture

kdecapite commented

Thanks for your thorough reply, Stephen. I've been reading through the handbook and am starting to see why #4 could lead to some trouble. I understand that Drupal was designed to be an integrated application between the front & back ends of a website, which is why it may not be what I need for some of my projects. I think it's ideal for 'community-based' or 'portal' websites (such as MySpace, PureVolume, etc.) where you have multiple roles and site visitors are also content contributors with their own login and profile. I'm not sure it's very effective, however, for a 'brochure' style of website (i.e. a website that is for one-way communication only from the company to the site visitor, such as a simple restaurant website or a photographer's online portfolio).

If I were to use implement Drupal for the latter type of website (i.e. an online 'brochure'), I naturally would follow your advice for #3 (disable the login block). How, then, would the admin be allowed to login? I'm assuming I would need to setup a sub-directory in the 'sites' directory with a 'settings.php' file enabling the login form. I would also want this sub-site to have it's own theme and interface, separate from the frontend site as well.

Regarding #5, please see my link for the current site template I recently created:

http://www.creationsitenetwork.com:8000/Hangar/www/
(hangar/wharf)

This is what I need to integrate into a phpTemplate site instead of my current templating scheme which requires a separate PHP file for every content page (all the HTML markup is contained in a stand-alone 'master template' file, however).

Again, many thanks for the input. I'm back to the handbook now...

- Kevin

sepeck’s picture

sepeck commented

Same way you do now.
http://drupal.org/node/31768
sitename/user or sitename/?q=user

see this post http://drupal.org/node/73422 for mention of http://www.bostonpizza.com/

One of my own sites (simple enough) www.ancientpathways.net
My sister in law one day asked me if it would be posible to have a newsletter integrated into her site. She was tired of emailing to 500 people in 50 message batches over a dial up line. So, I downloaded Simplenews, imported her users and poof! she had a newsletter on her site.

See this thread (http://drupal.org/node/31896) for a variety of approaches to doing brochere type sites. Drupal can easily be overkill for those types of sites, however, it can position you do easily add features and expand the role of a site when the owner is ready and in the meantime, you give them control over posting new content.

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

kdecapite’s picture

kdecapite commented

I'll spend some time reading through that thread you posted (the 31896 one) as I'm sure I'll find some helpful information in there. I'm still curious as to how I'd implement a completely different design (i.e. 'theme' or 'interface') for the login page itself, as well as all the other backend pages and tools.

The sites you showed me as examples just used the frontend/public website as their interface on the login pages (naturally, I couldn't get any further than that).

- Kevin

sepeck’s picture

sepeck commented

You can look at the civicspace theme for one method. There are some others inthe handbook. I don't do that. I design the admin interface into the theme itself.

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

kdecapite’s picture

kdecapite commented

I see that it's allowing for two different interfaces. The next step is learning how to use the phpTemplate engine so I can utilize my custom designs with Drupal. Thanks again, Steven. I appreciate your help!

- Kevin

sepeck’s picture

sepeck commented

Here you go. You should read this and see the integrated admin section screen shots
http://tedserbinski.com/2006/07/13/twit_tv

http://tedserbinski.com/files/twit_01.png
http://tedserbinski.com/files/twit_02.png

This is why I don't get the seperate admin theme method, but with Drupal's flexibility it can accomadate both views nicely.

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

kdecapite’s picture

kdecapite commented

Thanks for those links, that's a good read. I understand your confusion (for lack of a better word) in separating the frontend and backend interfaces. I think my push to separate these interfaces comes from client perception and "my old ways."

I've always built my content managers (CMS) as separate, stand-alone applications. Usually they even exist in their own domain and web space. So it's natural for me to continue doing this. I think in a "traditional" website, a separation of the two makes sense to the client.

They can reason, "This is my public website with all of my business information I want to make available to potential customers. Here is a separate link that only I know about with a secure login so I can update the site without calling my web developer." Since the CMS has a completely different design to it, the client is clearly performing administration duties there. When the design is the same as the public website, they may get confused as to "where" they are. I would fully expect quetions from my clients such as, "I like how I can update my homepage news teasers, but can you move that function off of my website? I don't want my customers to be able to change my homepage."

To us, this sounds rediculous. But to a non-technical client, they get easily confused because the two sites look identical (even though the CMS is password protected).

However, I think in less traditional web apps (specifically websites such as this one and the one you linked in your last post) that it makes more sense to NOT have a separation of frontend and backend interfaces. Modern websites are "community" based websites where regular site visitors are also content creators (such as you and I on this forum). For this, logins and profiles are required directly on the public website. It's simply a matter of "how much" a particular user is allowed to do (i.e. roles and permissions).

Hopefully, I will find a way to accomodate both approaches while still using Drupal. I'm starting to believe it can accomplish a LOT and I'm waiting for my production schedule to die down so I can dig into the handbook further.

Thanks for reading!

- Kevin