Generic looking login page

[Nick Teetzel]

Hello,

I've installed the script into an add-on domain that has not had anything installed yet
and when I type xxx I get a generic looking login page - not the
new colorful style...

I also get the courtesy page from my host - when I type in xxx (without the .com/delavo)

should I install my own page into my xxx - or can I do that through the Delavo script?

- or could I upload the Delavo script into xxx if it was a wordpress install? And then still make
Delavo the new directory like xxx

I hope this makes sense :D

Thanks,

Nick Teetzel


Hey now -Someone had a URL Deleted by Mod message on my post - and I never had a URL here?
I deleted it but it gave me a -1 Karma ... How do I get a good Karma to even me out?

I think I need to do some really good things to get me a + Karma :)

[Brian Collins]

Hello,

I've installed the script into an add-on domain that has not anything installed yet
and when I type in I get a generic looking login page - not the
new colorful style...

I also get the courtesy page from my host - when I type in (without the .com/delavo)

should I install my own page into my - or can I do that through the Delavo script?

- or could I upload the Delavo script into if it was a wordpress install? And then still make
Delavo the new directory like delavo

I hope this makes sense :D

Thanks,

Nick Teetzel



Hi Nick,

Use a generic page at your root directory - your domain.com or a wordpress blog or anything else you want to put there you cannot do that through Delavo.

Without knowing your domain name I cannot see what you mean about the new colorful style - having Delevo in the /delavo directory is the way to go.

Brian

[Willard Solomon]

Hello I am a new delavo user and I have the same problem. There are no colorful header or footer images showing on any of my pages All I get is 3 blue gray boxes No other color images Everything looks like its in the files But they do not show.

Thanks for any help
Willard Solomon
heres the installed link


URL deleted by Mod REASON: Cannot post a live link to your website in the
body of your post.
I orginally put the link in for visual reasons So people could see the generic look THATS ALL

[Willard Solomon]

Thanks Brain You are A GEM!


Willard

[Nick Teetzel]

Hi Brian,

If I want to use wordrpess as my generic domain - would you recommend uninstalling the delavo
script - before installing wordpress?

Thanks,

Nick Teetzel ;D

[Brian Collins]

Hi Brian,

If I want to use wordrpess as my generic domain - would you recommend uninstalling the delavo
script - before installing wordpress?

Thanks,

Nick Teetzel ;D


Hi Nick,

If you mean to install Wordpress as the front page to your domain and have Delavo in its own directory then no you do not need to uninstall Delavo.

Brian

[Nick Teetzel]

That's great Brian!

The advice you gave to Willard also corrected the generic
looking login page for me as well.

Thank you so much - your awesome! ;D

Nick Teetzel

[Yuzairy Samsudin]

Hi Brian,

If I want to use wordrpess as my generic domain - would you recommend uninstalling the delavo
script - before installing wordpress?

Thanks,

Nick Teetzel ;D


I never tried installing Delavo on the same path as WP.
What I'm afraid is that they may collide with each other since both serve dynamic pages from mysql.

E.g if you make a post that have have the same slug name as your delavo folder, then which one will take precedence?

If you're adventurous, then why not?
Let us know what's the result.

If I were you, I would install the blog in a subfolder.
That way they don't interfere with each other.

Eg
domain.com/blog
domain.com/delavo

[Brian Collins]

Hi Brian,

If I want to use wordrpess as my generic domain - would you recommend uninstalling the delavo
script - before installing wordpress?

Thanks,

Nick Teetzel ;D


I never tried installing Delavo on the same path as WP.
What I'm afraid is that they may collide with each other since both serve dynamic pages from mysql.

E.g if you make a post that have have the same slug name as your delavo folder, then which one will take precedence?

If you're adventurous, then why not?
Let us know what's the result.

If I were you, I would install the blog in a subfolder.
That way they don't interfere with each other.

Eg
domain.com/blog
domain.com/delavo


Hi Yuzairy,

Good advice (Yuzairy wrote an excellent WP book a number of years ago) as always.

As an advanced user, I sometimes forget that what I take for granted (i.e. watching out for using generated directory names the same as physical) is not always considered.

Brian

[Brian Collins]

Hi Nick,

A follow up on this.

I have a Delavo installation with a WP in the root directory now.

I have only come across 1 problem so far - local memberships are not working correctly when a customer tries to access them.

I will update this when I get a solution.

Brian

[Yuzairy Samsudin]

Hi Nick,

A follow up on this.

I have a Delavo installation with a WP in the root directory now.

I have only come across 1 problem so far - local memberships are not working correctly when a customer tries to access them.

I will update this when I get a solution.

Brian


That's not surprising. For Delavo to manage local membership, it uses Apache authentication to update the htpasswd file for the folder.

In the case of WP, the folder doesn't "physically" exists. It is dynamically served by WP database.
As such, Delavo can't get hold of the htpasswd.

So it looks having Delavo and WP have its own folder/subdomain is a way to go about it.

[Robert Lawless]

I have a similar problem, only not...

After I installed Delavo, any index.html that I upload into my
root folder (i.e. mydomain.com if Delavo was installed in
mydomain.com/delavo) that page shows blank.

I open it and view the source in IE and it shows a basic
html page before you input your data into it - html, head,
body and the like - but nothing that I inserted.

I have tried this with a .html and a .htm, careful to
transfer correctly as I usually just let cute-ftp handle
that, and both ways are the same.

Anyone have any response to why That is happening?

Have not had any problems with installing or using
Delavo yet...everything seems smooth.

Thanks in advance for any replies...

- Robert

[Brian Collins]

Hi,

A quick update.

I have been working on this at the .htaccess level and using another domain's .htaccess to check a few things.

On the other domain I have Contepass (TM) installed for the root and Delavo installed as normal in a sub-directory - everything (including a local membership) works just fine.

There are of course different commands in the .htaccess and it is down to figuring out which will allow the WP/Delavo installation to co-exist.

Contepass (TM) also uses an .htaccess in much the same way as Worpdpress.

Working on it...

Brian

[Yuzairy Samsudin]

Working on it...

Brian


I'll let Brian crack his head on this ;D

Thanks Brian!

[Brian Collins]

Hi Nick,

A follow up on this.

I have a Delavo installation with a WP in the root directory now.

I have only come across 1 problem so far - local memberships are not working correctly when a customer tries to access them.

I will update this when I get a solution.

Brian


That's not surprising. For Delavo to manage local membership, it uses Apache authentication to update the htpasswd file for the folder.

In the case of WP, the folder doesn't "physically" exists. It is dynamically served by WP database.
As such, Delavo can't get hold of the htpasswd.

So it looks having Delavo and WP have its own folder/subdomain is a way to go about it.


Hi Yuzairy,

Delavo is updating the passwords correctly in the local membership protected directory - it is the root .htaccess that is stopping access to the membership directory.

Brian

[Yuzairy Samsudin]

Congrats!

[Nick Teetzel]

Thank you Brian - That's awesome!

Nick Teetzel ;D

[Brian Collins]

Hi All,

My initial install that caused problems with WP as the frontend and a local membership I have discovered is server related.

I have an install, same WP frontend (even the theme) local membership and Delavo - no problems at all, did not need to provide the fix above.

Brian

P.S. I can also confirm that everything is fine with my installs where I have Joomla and Contepass (TM) on the frontend.

[bud roberts]

Brian,

Here's a swerve ball. Say you have your centralized DELAVO on one domain. It's servicing 3 tother domains. When a customer make as purchase on either of the three domains, how doe's one be sure that the right header/footer accoopanies the Thanks you or download page? Just a thought a had rolling aronnd and wondered if there was a "toggle" inside DELAVO to take care of this.

[Yuzairy Samsudin]

Brian,

Here's a swerve ball. Say you have your centralized DELAVO on one domain. It's servicing 3 tother domains. When a customer make as purchase on either of the three domains, how doe's one be sure that the right header/footer accoopanies the Thanks you or download page? Just a thought a had rolling aronnd and wondered if there was a "toggle" inside DELAVO to take care of this.


Bud,

The templates used by Delavo can be customized; either globally or on individual package basis.

Globally: Go to Tools - Templates
Package level: Select the 'Edit templates manually' radio checkbox when creating a Package

Rgds,
Yuzairy

[Brian Collins]

Hi,

As Yuzairy says - a package specific template (which is different for each domain or even each package), best to define them in the global templates are and then just select them from a doropdown list in the package record.

Brian

[Steven Hancock]

Brian, it's a little simpler than that page describes it.. I fixed the problem of password protected directories not working with Wordpress in the root by simply creating a 401 error document in cPanel. I didn't have to make any manual changes to my root .htaccess file and made no changes to the protected directory's .htaccess file. As long as the error document is there and the server knows about it, password protected directories will work fine. The problem is when the error document doesn't exist, the server returns a 404 error which gets routed through Wordpress because of the rewrite rules in your root .htaccess file.

[Brian Collins]

Hi Steven,

Yes, thanks for that.

This particular hosting account though is producing some strange behaviour - on another hosting account with the same setup there are no problems at all (possible because of a cPanel defined 401) so I still have some further digging to do (especially as it is my most expensive hosting account :) )

Brian

[Steven Hancock]

Of course another option would be to use John's "No More Grey Screens" script. I'm sure you're probably familiar with it. It uses the same .htpasswd that regular HTTP authentication would use, but changes the .htaccess so you get routed through a PHP login form instead of getting the usual 401 HTTP authentication.

[Brian Collins]

Of course another option would be to use John's "No More Grey Screens" script. I'm sure you're probably familiar with it. It uses the same .htpasswd that regular HTTP authentication would use, but changes the .htaccess so you get routed through a PHP login form instead of getting the usual 401 HTTP authentication.


Hi Steven,

Strangely enough I was getting some problems - not using NGMS - using John's little script for running a membership site.

This works on other hosting (even Dreamhost) without a glitch so it is definately server setup unfortunately :(

Brian

[Andre Foisy]

That's great Brian!

The advice you gave to Willard also corrected the generic
looking login page for me as well.

Thank you so much - your awesome! ;D

Nick Teetzel


However, for high security risk, it is NOT recommended at all to run a Wordpress installation from your web root. There's a simple technique you can find at wordpress.org that allows you to set wp in a sub-directory and still make it appears as your domain's main front page.

Regards,

Andre Foisy

[Steven Hancock]

What's the security problem with running Wordpress in your web root? I guess the chmod 777 thing could be an issue (but that's only slightly less of any issue for any other directory), but since I've been with HostGator for a while I won't host with anyone who requires or even allows chmod 777.. it's so much easier to install a script by just dropping it in and having it run without having to fool around with permissions.. lol

[Andre Foisy]

What's the security problem with running Wordpress in your web root? I guess the chmod 777 thing could be an issue (but that's only slightly less of any issue for any other directory), but since I've been with HostGator for a while I won't host with anyone who requires or even allows chmod 777.. it's so much easier to install a script by just dropping it in and having it run without having to fool around with permissions.. lol


Mmm... there are several reasons not to host WP in your root, a simple google "wordpress security" will send shivers along your spine ... one single good reasons is that hackers will use remote tools to hack several wp sites simply targeting yourdomain.com/wp-admin to knock and open your admin board too easily ... ... thus putting it in another folder known by you, not necessarily /blog, again too easy, it could be anything it doesn't matter, will render this task very difficult to be executed.

It's not the only action to take, but already helps much...

Andre Foisy

[Aaron A LaRiche]

In the case of WP, the folder doesn't "physically" exists. It is dynamically served by WP database.
As such, Delavo can't get hold of the htpasswd.

...Brilliant.






Working on it...

Brian


I'll let Brian crack his head on this ;D

Thanks Brian!


...and funny too!


Gabriel

[Steven Hancock]

Mmm... there are several reasons not to host WP in your root, a simple google "wordpress security" will send shivers along your spine ... one single good reasons is that hackers will use remote tools to hack several wp sites simply targeting yourdomain.com/wp-admin to knock and open your admin board too easily ... ... thus putting it in another folder known by you, not necessarily /blog, again too easy, it could be anything it doesn't matter, will render this task very difficult to be executed.

Interesting.. I kind of knew about the wp-admin issue, and since I'm the only person who should ever have access to wp-admin on my blog I've taken the "Matt Cutts" approach and locked it down with HTTP authentication and IP address restrictions in that directory's .htaccess file. Since I'm on a dynamic IP I've taken that one step further. Whenever my IP changes I navigate to a custom PHP script I wrote, which can only be accessed by SSL and isn't located in a very "obvious" place, and after entering a password (very long and very random.. a SHA1 hash of some randomly generated data from random.org) it updates the .htaccess file with my current IP. Now that I think about it, not installing Wordpress in the root might have been a much easier solution.. lol.. but I think my solution is fairly secure and probably easier than moving an already installed blog. Of course there are times when you'll need to allow other people to access your wp-admin, for example if you have "guest bloggers" or if you're running a Wordpress-based membership site and want to allow members to update their profiles. I'll definitely be googling "wordpress security" to see if I can pick up any more tips, I know one way to avoid most zero-day SQL injection exploits is to never use the default wp_ table prefix.

[Andre Foisy]

Mmm... there are several reasons not to host WP in your root, a simple google "wordpress security" will send shivers along your spine ... one single good reasons is that hackers will use remote tools to hack several wp sites simply targeting yourdomain.com/wp-admin to knock and open your admin board too easily ... ... thus putting it in another folder known by you, not necessarily /blog, again too easy, it could be anything it doesn't matter, will render this task very difficult to be executed.

Interesting.. I kind of knew about the wp-admin issue, and since I'm the only person who should ever have access to wp-admin on my blog I've taken the "Matt Cutts" approach and locked it down with HTTP authentication and IP address restrictions in that directory's .htaccess file. Since I'm on a dynamic IP I've taken that one step further. Whenever my IP changes I navigate to a custom PHP script I wrote, which can only be accessed by SSL and isn't located in a very "obvious" place, and after entering a password (very long and very random.. a SHA1 hash of some randomly generated data from random.org) it updates the .htaccess file with my current IP. Now that I think about it, not installing Wordpress in the root might have been a much easier solution.. lol.. but I think my solution is fairly secure and probably easier than moving an already installed blog. Of course there are times when you'll need to allow other people to access your wp-admin, for example if you have "guest bloggers" or if you're running a Wordpress-based membership site and want to allow members to update their profiles. I'll definitely be googling "wordpress security" to see if I can pick up any more tips, I know one way to avoid most zero-day SQL injection exploits is to never use the default wp_ table prefix.


Yep, you can find the method to run WP in its own dir,
while still being viewed as in root by visitors here:
http://codex.wordpress.org/Giving_WordPress_Its_Own_Directory

And of course the table prefix is s very good method as well.
Both combined provide a very secure solution against most of the
hackers, unless you're a bank or hold State secrets :D , as they'll
go after the thousands of easy ones domain.com/wp-admin out there.

I do all my WP install like this, and a bit more, for me and my clients,
it's included with my special package (sig).

Andre

[Mitch Powell]

This has been a great lesson in site security.

Thanks Andre, Brian, Steven, et al.

;)

Mitch