I'm trying to understand why I have so many errors on the remote server but on local server everything's fine.
Any idea why I'm getting all of these error?
Thank you in advance!
looks like there's a mess with the cache files. Try disabling the cache in your remote app.
Do this in /app/Config/core.php
Look for the following:
//Configure::write('Cache.disable', true);
and remove the // to make it works.
Best,
Ok guys, I have no idea what generated these issues but after changing to a new hosting the issues disappeared. Always check online for hosting reviews to make sure it's a good one or you'll end up with some odd things happening on your website. Thanks y'all for your help and time.
Related
Thanks in advanced for looking at my post! I developed this Commerce Kickstart site locally using Aquia Dev Desktop and everything looked and functioned great. When I post it to the server, I get the WSOD, and an error in the error_log:
PHP Fatal error: Call to undefined function delta_get_current() in /xxx/xxx/xxx/profiles/commerce_kickstart/themes/omega/alpha/includes/alpha.inc on line 222
This is a site that had been working fine remotely also, except for an issue with the checkout. (the original reason for taking it down.) I had to refer to a backup copy of the site, make some changes to get it to be more recent and then post it. That's when I received the WSOD and Php Fatal Errors.
If you have any advice on how to fix or where to proceed, please let me know. Also, let me know if you need any more info.
Thanks again.
Jason
You need to make sure that you're working with the right module and theme versions. See what you can do to update Delta to fix it, also update Omega.
can someone pls tell me how bad the found malcode in one of my webserver is ?
I found it in public_html/outlet.
here is the code pastebin
i deleted the directory and try now to search my logs.
thanks for your answer
tango2000
It isn't evident how bad it is. However, the real bad part is that they were able to inject code into your server.
Since you don't know how did they do it, it doesn't matter that you deleted the folder that contained the script. The vulnerability is still there and they will hack you again eventually.
First timer.
I am working on a web application with Google-app-engine.
The code is mainly servlets and jsp.
When I run the local server and try to browse the site with IE9 it looks great.
But, when trying to do so with firefox10,11 or with GC, all I get are blank pages.
I deployed one page to the server and the problem reaccures.
If needed, I will add source-code or link to the page, but currently I've got nothing. Any ideas? Thanks!!
Thanks for the comment. Still learning my ways around here, after being a loyal reader for a few years.
Anyway, I found it. It took me about 2 months, but I did. It is as simple as that:
Seems like while IE is a bit more flexible, FF and GC can't parse a path with '/'s instead of '\'s.
I got it when I installed Firebug for firefox and it ran over the code and implied that the URL for the images is invalid. A short look for that error message got me to that conclusion.
Thanks a lot!
I am working on a project using CakePHP and have been trying to update some views. The file uploads to the server correctly but the system seems to serve the old version. I am kind of new to Cake so I'd appreciate any pointers.
Thanks!
I experienced the same thing. The trick is to clear out all of $YOUR_APP_FOLDER/tmp/cache when deploying new code, to erase any conflicting cache.
cd $YOUR_APP_FOLDER
rm -f tmp/cache/*/*
It could be that view-caching is enabled, check core.php for
define ('CACHE_CHECK', true);
Where are you putting the views? Also, make sure the /tmp/cache/ folder doesn't have any lingering crap in it that might be getting rendered.
Edit:
If you set the debug level in config/core.php to something higher than 0, caching will be disabled and you'll get nice error messages if something poops the bed.
The only way to ignore cache of views is uncommenting
Configure::write('Cache.disable', true);
in core.php
So the last couple of days my dev webpage for ssrs has been looking really weird, as if it's not getting styled by css at all. I'm not the only person that is seeing it like this. We just rebooted the server and it didn't have any effect. If you know what it causing this, please help.
another symptom is that i can't modify security settings now.
If I were you, I would view the page using FF (firebug), and take a look in the head to see whether the CSS is being imported.
If it is, make sure the path is correct.
A couple of general things come to mind...
Make sure your IIS application/virtual directory settings are correct especially if you are using SSRS2005. The default IIS applications are "Reports" and "ReportServer"
Make sure the NTFS rights are correct for Local path. For example the default location for ReportServer is "c:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting Services\ReportServer"
In my experience when strange things like this are happening there are user rights/access issues. Especially when you can't modify security settings.
HTH
Well it kinda seems to have fixed itself.
This may be a bit naive, but have you tried an offline version of the code?
Get the generated HTML via "view source" in your browser of choice, then get the stylesheet by accessing it directly from the same browser, using whatever the path is from the html (I recommend Google Chrome, as the view source provides clickable hyperlinks within the source). Put them both on your desktop, making sure the relative paths are preserved, and see what it looks like offline.
I'm sure that the server/Microsoft produce all of this code and so it's SUPPOSED to work, so a missing closing tag or misplaced semi-colon is probably not the answer, but I have found more than once that pulling my output off the server and onto my desktop has made the problem go from mysterious to "Oh! Duh! /styles/style.css, not /Styles/style.css" etc etc.
The problem can only be with your server if www doesn't have read/execute access to all of the right folders. I find this really unlikely, but it's easy to check by simply trying to view the source code of the CSS. If you can, the problem is post-server output.