Installation problem - db connect error 1045

[pawel]

Hello there!

First of all I want to say hello to everyone. This is my first post, although I've been working with ProcessWire for some time now. I must say PW is a great little CMS/CMF and I'm learning so much from it. Here's m problem:

I've uploaded a fresh copy of PW into my clients ftp. The first message that I get after i visit pw directory in the browser is:

Error Exception: DB connect error 1045 - Access denied for user ''@'localhost' (using password: NO) (in /navigroup.pl/wire/core/ProcessWire.php line 95)

I didn't change any of the files, only uploaded them to the server. Can anyone tell me what might be the problem here?

Thanks,

Paweł

[teppo]

Hello there and welcome to the forum!

Just to make sure, you uploaded a fresh install package and definitely not a pre-installed site, right? You didn't install this somewhere else (local or your own server) before this?

I'm asking this because it seems like PW is expecting database user, password and hostname. And that shouldn't happen unless this is an installed version. You could also try downloading new fresh package from https://github.com/ryancramerdesign/ProcessWire again, just to make sure.

[pawel]

Yes, I've uploaded a fresh install package, downloaded directly from github. A little update: I've visited the install.php file directly and the installation went good. But there's something wrong with paths. I've my installation in http://domain.com/direcotry, but ProcessWire thinks it's in http://domain.com/ because all of assets are served from that domain.

For example:

there's an image that in html has relative path "/site/assets/files/1/westin_interior1.jpg"

PW path for that file is

http://domain.com/site/assets/files/1/westin_interior1.jpg

Actual path is

http://domain.com/directory/site/assets/files/1/westin_interior1.jpg

Is it problem with htaccess or config file?

[teppo]

Not sure if this would help, but have you tried setting the RewriteBase-option in htaccess?

"Optional: Set a rewrite base if rewrites aern't working properly on your server."

[pawel]

Not sure if this would help, but have you tried setting the RewriteBase-option in htaccess?

"Optional: Set a rewrite base if rewrites aern't working properly on your server."

Yes, didn't help. Any ideas?

[teppo]

Sounds a lot like htaccess wasn't properly supported there. It IS supported at some level, right -- what does phpinfo() say about it?

[pawel]

I don't see anything about htaccess, but there's some info about php variables:

_SERVER["SERVER_NAME"] = domain.com
_SERVER["REQUEST_URI"] = /directory/info.php
_SERVER["SCRIPT_URI"] = http://domain.com/directory/info.php
_SERVER["DOCUMENT_ROOT"] = /

Maybe it has something to do with document_root variable?

[teppo]

Sorry @pawel, my last post was pretty vague. I meant mod_rewrite -- is that mentioned in the output of phpinfo() and if it is, what are the values of http_mod_rewrite and http_redirect_mod_rewrite? Or if those don't exist, do you see _SERVER['REDIRECT_HTTP_MOD_REWRITE'] and is it "On"?

IMHO document_root itself shouldn't make any difference here, unless I'm confusing something.

[pawel]

There's nothing in phpinfo about mod_rewrite or any of the things you mentioned. I think this server host is using some custom made mod_rewrite module and not everything is working properly...

[teppo]

So it seems. Unfortunately I've no idea how to work around that problem -- I hope someone else does.

You might want to check from your client / whoever manages that server if there's any chance they could fix this. OR you could always try to persuade your client to switch servers -- this kind of problem is quite likely to affect pretty much any existing CMS and many other applications, not just PW -- but quite often that's not exactly simple task either..

[pawel]

I've managed to make some steps forward. In index.php I've commented lines 42 - 54 and replaced them with hardcoded variables

$httpHost = 'http://domain.com';
$rootURL = '/directory/';

The fronted works fine, but admin panel does not. PW doesn't display the pages tree, and every time I want to edit something, for example a template - link directs to:

http://domain.com/directory/processwire/setup/template/edit?id=29

I get a 404

404 Not Found
The request /directory/processwire/setup/template/edit was not found on this server.

Any ideas?

[pawel]

Another discovery - when a domain is redirected to directory on ftp in which PW is installed (so the http://domain.com is where the pw installation is) there's only a problem with admin working properly. It looks like this:

[ryan]

Pawel, can you PM us a link to your phpinfo file? I tried alergolog.org/directory/info.php but it wasn't there. Also while we troubleshoot, it would be best to set the index.php back to how it was, just to limit the number if variables here.

Lastly, when I go to alergolog.org, I get the ProcessWire default profile homepage. If it is installed in /directory/, it shouldn't be possible for it to display at your site root. Have you moved the installation from the subdirectory to the root? (I'm guessing so from your previous message, but want to confirm).

Regarding the last issue you are seeing with an empty page list, please PM me a username/password to login to your admin and I can find out what it is. You might also be able to tell by looking in your javascript console to see if there are any errors. However, like Teppo, I suspect there's something odd going on with the server's rewrite engine, so it would be good to get a look at the phpinfo.

[pawel]

Ryan, I've PM you info which you've asked for. Thanks

[ryan]

I've taken a look at the phpinfo and noticed the server is not running Apache. Instead it's running something called IdeaWebServer (a server I'm not familiar with). It looks like IdeaWebServer isn't close enough in terms of Apache compatibility. I think there are several potential problems with running on a server that is not 100% compatible with Apache. Beyond just getting it to work in the environment, ProcessWire depends on Apache-specific directives in some areas of security, like blocking access to protected files and directories. The same goes for many other CMSs and web applications. Even if we could get things working here by modifying core files, I would be concerned about long term stability and security in this environment, since it isn't fully Apache compatible.

I would switch web hosts if I were you. Still, if you want to keep at it, it looks to me like the problem lies in the RewriteEngine. As soon as there are GET variables present in the URL, it appears that the RewriteEngine gets disabled. For instance:

http://alergolog.org/templates/

vs.

http://alergolog.org/templates/?id=1

This is not correct behavior for the server's RewriteEngine, and is preventing you from even being able to use the admin. Any idea why IdeaWebServer is disabling the RewriteEngine when GET variables are present? I suspect this behavior would interfere with a lot of applications, so am a little surprised by it. But maybe it's something that your web host can advise on. Please let us know what you find.

[pawel]

I contacted the server administrator and I'm waiting for a response. But in the meantime I've installed Wordpress and checked if it has a problem with GET variables in the URL, and it doesn't. Here's a link http://massgravity.home.pl/wordpress/

The RewriteEngine seems to be working fine in this case.

http://massgravity.home.pl/wordpress/sample-page/

http://massgravity.home.pl/wordpress/sample-page/?id=2

[pawel]

For anyone else that is using home.pl services. Everything is working now. Admin commented 113 line in .htaccess which is:

#RewriteCond %{REQUEST_URI} "^/~?[-_.a-zA-Z0-9/]*$"

Can you tell me why it works?

[teppo]

Great to hear that it works, although I'd be somewhat careful here:

That condition checks if URL is valid and thus removing it could potentially allow non-valid queries into PW which in turn could result in strange behavior and/or security issues. I'm not an expert in this area, though, so I might be worried for no reason -- of course Ryan knows best how this stuff works so I'd ask for his opinion before implementing this "fix".

Most likely better option would be to determine how their rewriterules work and create one that's specific to IdeaWebServer to ensure that URL's still get filtered correctly.

--

Somewhat offtopic, I did some research conserning IdeaWebServer and you might want to take a look at this (still unresolved) WordPress ticket: http://core.trac.wor...org/ticket/9763. So clearly there are existing problems with other platforms too.

You did say that WP works now though, so it might be that they've fixed that problem and the ticket was just forgotten.

Anyway, the point of above comment is that if this really is software developed and maintained by one specific service provider, then that's not a very good situation for it's users. But that's naturally just my opinion -- on the other hand it does seem like they've got very good customer service, which always makes things easier.

[diogo]

Do this test to see if everything is working properly concerning security

[teppo]

Do this test to see if everything is working properly concerning security http://processwire.c...ver/#entry10801

That's definitely a good start, though even if those files are inaccessible, I'd still be a bit worried about any invalid parameters being passed to ProcessWire.

[pawel]

The test returned a 403 (forbidden) for all of the links. So far so good

[ryan]

That's definitely a good start, though even if those files are inaccessible, I'd still be a bit worried about any invalid parameters being passed to ProcessWire.

I agree with this. But in this case, I think it should be okay because PW performs a secondary filter on the URLs that go into it. That .htaccess line that was removed is more like a first defense to to save resources and not load PW at all when we know the URL is going to be invalid. Removing that line makes things a little less efficient, especially when getting bombarded by somebody's vulnerability scanner. But I don't think it is a security concern. So if removing that line makes it work on IdeaWebServer, then it should be okay. It would still be good to find a replacement rewrite rule, but not an urgent thing.