I have just moved a silverstripe install to a new joyent smartos server. Not being familiar with Linux, this was still relatively easy.
I am new to silverstripe as well, but the team here has developed on it for years.
I have the site up and running on the new server, but have not pointed the domain to it until we can thoroughly test it. So I am accessing it from it's ip address. The site displays fine and the sub pages work as well. When I navigate to the '/admin' page, I see a silverstripe page that states the page cannot be found (not an Apache 404). I copied over the .htaccess and the _config.php from the old server, so there should be no issues.
I have done a /dev/build with no errors and I can log in through the security page, but I just cannot get the /admin to come up. I am lost after spending the whole morning surfing google to find the answer. Any help would be greatly appreciated.
UPDATE:: I installed a fresh version of silverstripe into a subdirectory on the same server. Works perfectly, so that rules out any PHP issues.
I have also tried /index.php/admin with no luck.
Thanks,
Ben
I was having this problem as well. None of the solutions I found online worked for me, but I managed to figure it out.
I had apache running as a non-standard user, and the problem turned out to be that the webserver was unable to save session data for the logins.
The solution in my case was to chown root.myuser /var/lib/php/session. Once done, the admin page loaded fine.
If /admin is not loading at all and there is no 404 error, there is a high chance of a PHP error. And that should be logged in the webserver's log file. This will depend on your operating system and probably on the Joyent environment (not familiar with that breed of cloud computing). On Debian, Ubuntu, and some more it's /var/log/apache2/error.log (assuming you're using Apache).
If I had to guess, I'd say the permissions of assets/_combinedfiles/ are bad. The webserver tries to create some combined JS and CSS files there (specifically leftandmain.js and cmsmain.js) and if it fails, you might get the dreaded white page of death in /admin.
Related
I seem to have an issue with the file preview in the documents which throws me a xyz and logs me out. See image here
It doesn't matter what I change including removing the / from the root and site address in config php file i just cant get it to work.
Ive followed its4you install instructions with the correct chown and owner permissions etc for the full install. I then decided to set a brand new instance up on a new server and it is the same. So i reconfigured a different server on amazon web services running ubuntu... exactly the same issue.
I have a similar issue when i installed pdfmaker and tried to browse server in the editor (fck possibly), it would show me blank thumb nails, if i click one then save it would close the session and log me out.
I have several versions of 7.1 running on the same servers without issue.
Any ideas?
Found the answer to this. Whilst browser through two comparative server setups I noticed "Varnish" was enabled on the new instance running VTiger 7.3. I turned this off and hey presto, issue resolved!
I installed the Shopware 5.4.6 community shop.
I now wanted to make changes in the basic settings what is answered with "Basic settings will be loaded" (BTW i use german version so i got "Grundeinstellungen wird geladen").
All other points can be displayed without problems.
PHP Version 7.0.31, Linux 3.16.0-6-amd64, Apache, Shopware 5.4.6
backend UI shows no errors in Shopware logs
backend UI shows shows nothing in the system log.
Resolved / Done / Solved / Workaround:
Tried different things. Also read the apache error logs. did not help.
How I got it work:
have uploaded and installed a fresh shop in a subfolder of the shop. this time the basic settings were accessible.
So I just wanted to give it a try again (in the home folder)
So i deleted (all inside the shop home) and uploaded again. istalled. and even then the basic settings were accessible.
I noticed:
during these installations the assigned rights for individual files were no longer required / required / remindet during the installation.
may because I had recursively set writing permissions in the shop folder (sometime yesterday when trying around).
I have not tested now if the error occurs again, if I do not give this home folder at the beginning writing permissions recursivly for php. uploaud just takes too long at this lame server. it took a whole hour to empty the content folder (FTP access).
Too bad the shopware 5.4.6 could had no error messages. Maybe too rare a case.
I have two openx 2.8 servers running here. The issue is that trying to open the admin page redirects me to the full path www.myserver.com/www/admin/index.php with blank screen. Still I can access www.myserver.com/www/images/, delivery etc. I tried a lot of stuff without any success.
this one doesn't work for me OpenX Admin not accessible
I had something similar happen to me last week. Check your configuration file in the /var folder of your openx installation, probably called something like www.yoursite.com.conf.php. Mine was corrupted. I suspect outside malicious activity, especially since there are known vulnerabilities in OpenX.. I'm currently looking at upgrading to Revive Ad server, which is the successor and is supposed to offer a complete upgrade path.
I have a fresh wordpress 4.0 install on my server for a specific domain and when I make changes to any of the theme files it won't show up in the browser for a few reloads. I just add "asdf" to the theme file to test changes. I can refresh 20 times but no changes show up until like 20 seconds later.
What I have tried:
Turned off firefox's cache.
Turned off wordpress cache.
Tested other domains on my server with wordpress and they work properly.
Installed wordpress with "server installer apps"(3 times) and also with manual installation.
I refresh with ctrl+f5
Tried with firefox and with chrome, same results.
Its a fresh install so no plugins, no settings changes. There is no caching and my other domains work properly. No errors show up in the console.
I have no idea what the problem could be. My server company, mediatemple, said it could be my ISP, but other domains on my site work properly from the same computer/network. For some reason the problem is specific to this domain and the problem persists through all the themes.
I don't know what to do next. Any suggestions would be greatly appreciated. :)
Update:
Have tried manual install of wordpress 3.9 and that does nothing.
I added a new folder to the root and in that folder I added a file called index.html to test if this file, which is unaffected by wordpress, would show instant changes and IT DOES. So the problem seems to be based within wordpress and specific to this domain.
I spoke to Mediatemple for the 3rd time now and this guy was much more helpful and he actually solved the problem.
When you add a domain to mediatemple it automatically sets the PHP version to "FastCGI", which normally is fine, but it caused problems specifically on this one domain's wordpress install for unknown reasons. So he switched the PHP version to "CGI (Stable)" and that fixed every problem.
I hope this will be helpful to someone in the future. :]
Bit of an obscure one this. My setup is all running on my local Windows machine; I've got NetBeans IDE installed, a local XAMPP server with XDebug running, and an installation of Moodle with some custom addons in the mod directory.
I can happily create breakpoints in PHP pages (including the main Moodle ones), but any breakpoints I place on php files in the mod directory never fire (on my mods, or any of the inbuilt ones). I thought Moodle might be doing some "magic" to display files in the mod directory, but my browser shows the url as http://localhost/moodle/mod/view.php - and that's the file I've set my breakpoint in.
Has anyone got any experience with debugging Moodle addins, or could possible point me in the direction of how to troubleshoot the breakpoint not firing? I've tried the Moodle site, but can't find anything relevent.
Actually, I think I've figured it out. If I tell it to debug that particular file it will 404 (it doesn't put the directories in, guess it's a bug), but if I then manually go to http://localhost/moodle/mod/view.php?XDEBUG_SESSION_START=netbeans-xdebug (which errors, no parameters are being passed in), and THEN manually navigate to Moodle then my mod breakpoints fire correctly.
All very bizarre, but it seems to be a usable workaround. I'm guessing the mods are running under some kind of different PHP session.
I'll keep this answer here in case anyone else has this bizarre problem.