XODA one click install problem

#1

Hey I just tried to install the new XODA and it says it installed fine even though it claims to have installed to http://www.subdomain.mysite.com// (interestingly the one click install of ‘Lime’ that I just put through did the same thing with the // ) this then takes me to the initial login page but when I try to login with firefox it comes up with an error of “The URL is not valid and cannot be loaded”, if I try with chrome it just does nothing. Attempting to login with firefox at http://www.subdomain.mysite.com/ without the extra / results in the same error. Trying just subdomain.mysite.com brings up “ERROR: no permission to access anything!” just above the login box. This same ‘no permission’ error is present on all versions of the page when trying to login with chrome.

In Opera it tries to login to http://0.0.0.0/?log_in so I checked out index.php and the form action="<?=PHPSELF;?>?log_in"

PHPSELF is defined at the top of index.php as
[php]define (‘PHPSELF’, dirname ($_SERVER[‘PHP_SELF’]) . ‘/’);[/php]

So I tried to define $_SERVER by adding
[php]$_SERVER = ‘http://www.subdomain.mysite.com/’;[/php]
at the top of the config.php file which did absolutely nothing.

As you can see I am a noob but any help would be greatly appreciated, and obviously the code doesn’t actually say subdomain.mysite.com.

#2

Hi Kris,

sorry for the late reply but I was working and my profession has nothing to do with IT, so I have to find some time off work to try to address possible problems.

[quote]I was wondering if you’d had anyone with similar troubles to me already with XODA.
[/quote]

Nope, you are the first one! :slight_smile:

[quote]I also tried chatting to one of the dreamhost support people but they just said it was third party so couldn’t help me.
[/quote]

That’s true! They state this on the front “One-Click Installs” page.

[quote]One thing I just noticed is that if I set ROOT_DIR to something which doesn’t exist it creates the directory, so it is doing something.
[/quote]

That’s what XODA is supposed to do.

Anyway, let’s talk about your problem.
Double or single slash ("/") is considered as the same thing under Linux/UNIX, so no wonder that there is no change in the behavior.

I don’t know why this happens.
The message “The URL is not valid and cannot be loaded” is not part of XODA and I don’t have any idea why it comes at all. Can you write down the URL which is tried to be loaded?

Is this the URL? This is of course not a valid URL!

Here are some suggestions:
[list]
[]Could you please make sure that you don’t have a ‘.httaccess’ file where XODA was just installed? Or just try to delete the one there and try again.
[]Try to uninstall XODA (over the One-Click Installs menu) and then reinstall it.
[*]Try to install it in a different directory (like http://www.subdomain.mysite.com/xoda/).
[/list]

I developed XODA entirely on DreamHost and never had a problem. I have no other report about anything even loosely related to the problem you describe. It must be something small and totally avoidable.

Please try the suggested solutions and drop me a message to let me know, how it behaves!

Thank you so much for testing XODA! I hope you would be able soon to enjoy it!

Best,
:slight_smile:
Ivo

#3

Yeah the URL not valid error is a firefox thing which is why I tried it in Opera which gave me what I’m assuming it’s trying to direct to http://0.0.0.0/?log_in

I just tried changing the form action to submit to index.php/?log_in rather than the phpself which stopped the url not valid error but just returns XODA’s “ERROR: Login failed.” error

There’s no .htaccess file in there and I reinstalled it once but I’ll try reinstalling to subdomain.domain.com/xoda as you suggest.

Thanks for your help, I was actually amazed you got back to me so quickly.[hr]
That worked, I can’t believe it was so simple, thanks heaps. I’ll be sure to let you know how it all goes

#4

PHPSELF is basically pointing to index.php.
Make sure you login initially with username: admin and password: xoda (which you should change after that!).
The “.htaccess” file is not part of the XODA installation but is generated automatically the first time the script is run, e.g. by the browser. It should do the job with the redirect to more user-friendly URLs.
I hope it will work, because I run out of ideas. :slight_smile:

XODA worked nicely for years for my personal needs and, since I really couldn’t find anything similar (surprisingly, because it actually offers only basic functionality) , I absolutely appreciate any feedback to make it better and more popular.
Thank you for sharing your experience! :slight_smile:

#5

Yeah it’s working great now, thanks again.

The non-working version also didn’t have any style info loading. I tried to change the subdomains directory to /home/user/domain/xoda so that subdomain.domain.com would point to subdomain.domain.com/xoda and it went back to the same problem. So now I’ve got it installed at domain.com/xoda with subdomain.domain.com cloaking it.

How hard do you think it would be to give normal users the ability to modify files but not other users accounts or overall settings? I’d prefer to be able to set groups for users and then permissions for the different directories but that would no doubt be far more complicated.

The logo that I put in the layer also seems to disappear when you’re in a third level directory, but then in the fourth level its back again. Doesn’t really matter, just thought it was interesting.

#6

It is great that it is working now, even though I still don’t understand, why you had the problem on the first hand.

I thought about implementing different groups of users with different ROOT_DIRs but decided that this would go beyond the current goal of the project.
However you can use different instances of XODA. Just copy index.php to e.g. users.php and config.php to e.g. config.users.php. Then set different ROOT_DIR in the new config file and let it be included in users.php (instead of the default config.php), no need to make another copy for functions.php or the javascripts.
I know it is not a good solution but you can get what you need if you play this way.

I think I know what you mean with the disappearing picture and in deed it is a bug which will be fixed in a future release.

Thank you!
Take care and have fun! :slight_smile:

#7

That didn’t seem to work but it’s working fine as it was meant to, I don’t want to take up too much of your time, especially while you’re at work.

I made a new functions.php file too as functions-user.php because it references the config.php file, and I replaced all the functions.php and config.php with functions-user.php and config-user.php within the user.php and functions-user.php files. Then I changed the ROOT_DIR in config-user.php to user-files/ and the META_DIR to .user-xoda/

user.php works, and created the new ROOT_DIR but then logs me into the original xoda index.php

#8

Yep, sorry that I didn’t think of that…
Open users.php and change

to

or to

and it should work.
We should be able to get a solution to this problem. :slight_smile:

#9

Changing to either allows me to login but its not loading the style.css or functions.php since the settings, upload, transfer and create links don’t work.

#10

It is probably better to isolate the new instance in another (sub)directory since further code changing is not in relation to the simplicity of just having subdirectories with as many groups as needed.
Note that e.g. settings will not work in another instance if you have one already opened in the same browser. You would get collision of the sessions. But the different user groups are not supposed to work on the same browser, so it shouldn’t be a problem in reality.
Good luck! :slight_smile:

#11

Yeah cool, thanks again for all your help and its a great bit of software.

This may be a stupid question but there’s no way to rename files is there?

#12

There is --> http://xoda.org/article/xoda-manual#rename :slight_smile:

#13

Kris, the problem with the “wrong URL” was confirmed by another user and I could reproduce it. It is a bug with the PHPSELF constant being defined wrongly when XODA is installed in a root directory of a domain (e.g. subdomain.mysite.com). A subdirectory works, as you know (e.g. subdomain.mysite.com/xoda).
I am working on this problem and the next version (0.1.4) will be released probably today. Please check sf.net/projects/xoda or freshmeat.net/projects/xoda for update!
Just wanted to let you know that it was not you but me having done something wrong. :slight_smile:
Thank you! :slight_smile:

#14

I’m having trouble along these lines:
I just installed XODA with the one-click installer, no problem.
I renamed config.sample.php to config.php, and made the following changes:
–> changed ‘admin’ to ‘username’ on line 3
–> changed the long hash password to ‘newfakepass’ on line 5
–> changed the root directory to ‘home/username/xoda/’ on line 9

and when I point my browser to www.mydomain.com/xoda, the XODA login screen comes up, but when i input ‘username’ and ‘newfakepass’ in the appropriate boxes and hit login, i get a yellow box at upper right, ‘ERROR: Login Failed.’

what gives?

thanks,
alex_p

#15

Hi Alex,

since the md5 sum of the password is what is verified, you should not change the long hash password this way.
After changing the username to say “username”, you should login with:
Username: username
Password: xoda
Then go to Settings -> Parssword and change the password from there, like described in the XODA-Manual.
For your convenience: the original md5-sum of the password “XODA” is ‘a68e142815fdda868de0551fc6675e65’ (withouth the quotes). You could change the password to this md5-sum in config.php and login like suggested.
Thank you for testing XODA and don’t forget to give feedback after you get some impression! :slight_smile:

#16

Ah, ok. I did what you suggested, and the problem is solved. Thanks so much.

#17