I've been modifying a module and for some reason prestashop does not take into consideration the code modifications in module.php.
I've made modifications a while back and I need to modify it again due to an update that raises an error, the problem is that I get the error even if I remove said line.
I get this type of error: PHP message: PHP Notice: Undefined index: ordersorderFilter!active in /modules/module/module.php on line 104
I've commented first than removed that line but I still get the error.
It seems like there is a cache somewhere that I can't find, I've deactivated all possible cache in prestashop, activated debug mode, deleted the dev and prod folders in /var/cache/ but I still get the error.
I've used grep on the server to try to find that line, and when I delete it from the file I can not find it anywhere else on the server (but can find it if I add it).
Anybody has any idea?
Thanks a lot!
Prestashop does not perform any kind of caching on the modules PHP files so the problem lies elsewhere or at "lower level" (webserver / proxy ie.).
So check your environment for server-side caching, proxies or PHP accelerators such as opCache that may not serve changes from the source server.
Also try renaming or deleting the offending file altogether and see if the error changes, if not you might simply be looking at the wrong file :)
Related
Until recently everything was working well. Now, when I try to save (create or update) any page or post I get error message at top of the form "Error - There was an error when trying to save the form".
In error log I see this error:
“Uncaught PHP Exception Sulu\Component\Rest\Exception\InvalidHashException: “The given hash for the entity of type “Sulu\Bundle\ArticleBundle\Document\ArticleDocument” with the id “9e0720a7-5565-4a6f-a735-8a186b8fef9b” does not match the current hash. The entity has probably been edited in the mean time.” at /var/www/html/vendor/sulu/sulu/src/Sulu/Component/Hash/RequestHashChecker.php line 53"
Tried clearing symfony cache, website cache from admin, restarting docker containers.
I'm totally unaware that I did something to cause this error. Please help.
Update: strange thing I just noticed. When I try to save some article and I get that error and go back to overview page (where i.e. all articles of that type are listed) then I see unchanged article title. But when I click to edit it I see changed title?!? Like title on overview page and title on edit page are not used from the same place? How is that possible?
Update:
Now even I setup once more project from scratch saving articles causes that error. Some more info:
In stack trace last command executed is:
in vendor/elasticsearch/elasticsearch/src/Elasticsearch/ConnectionPool/StaticNoPingConnectionPool.php (line 64)
an it shoots out “No alive nodes found in your cluster”.
And while I'm setting up the project when executing:
php bin/console ongr:es:index:create
I get error:
{"error":{"root_cause":[{"type":"resource_already_exists_exception","reason
":"index [su_articles/sWs5F1uzSFO8bFiZqF1Egw] already exists","index_uuid":
"sWs5F1uzSFO8bFiZqF1Egw","index":"su_articles"}],"type":"resource_already_e
xists_exception","reason":"index [su_articles/sWs5F1uzSFO8bFiZqF1Egw] alrea
dy exists","index_uuid":"sWs5F1uzSFO8bFiZqF1Egw","index":"su_articles"},"st
atus":400}
And when I run:
php bin/console ongr:es:index:create --manager=live
I get similar:
In Connection.php line 675:
{"error":{"root_cause":[{"type":"resource_already_exists_exception","reason":"index [su_articles_live/Pissm9ycRj-o79K4wrrD
AA] already exists","index_uuid":"Pissm9ycRj-o79K4wrrDAA","index":"su_articles_live"}],"type":"resource_already_exists_exc
eption","reason":"index [su_articles_live/Pissm9ycRj-o79K4wrrDAA] already exists","index_uuid":"Pissm9ycRj-o79K4wrrDAA","i
ndex":"su_articles_live"},"status":400}
Also to mention that now saving pages works, but saving articles doesn't.
This solved the issue on ElasticSearch index creation for me:
php bin/console ongr:es:index:drop --force
The error can happen in the following cases.
Expected Case somebody else did edit the same article like you and did save it
Unexpected Case your phpcr cache is not in sync
Unexpected Case you have a multi server setup but your cache.app is not configured to use a central cache
So if its one of the unexpected cases first you should clear your cache.pools with:
bin/console cache:pool:prune
If you have a multi server setup make sure you configure a central cache. Most use in this case a redis-server which you configure in your cache.yaml e.g.:
# config/packages/prod/cache.yaml
framework:
cache:
default_redis_provider: "%env(resolve:REDIS_DSN)%"
app: cache.adapter.redis
Also make sure that you use the latest version and maybe update your phpcr cache configuration based on the sulu/skeleton: https://github.com/sulu/skeleton/blob/2.x/config/packages/prod/sulu_document_manager.yaml, there you could when performance doesn't matter in your case disable the phpcr cache, I would not recommend that.
I have written a small Symfony2-Webapp. This worked on win in dev and prod. Than I uploaded all files to the provider and run into some issues:
The log-file tells me, that the twig-engine can't find a view. This helped, because a saw, that I had to correct one capital (index instead of Index) - it's always the same developing under windows and having production under unix.
I corrected the file and uploaded it. Than I deleted the cache (no console).
Still, the error resists!
What can I do?
New informations:
The problem exists, when not warming up the cache (dev and prod). If using console cache:warmup, than the cache is generated right.
As I found out, the in one generated file, the function 'getTemplateName()' is wrong. All other references in that file are correct.
Sadly, I have no console on my server.
EDIT: Answers:
1) Error is: request.CRITICAL: Uncaught PHP Exception InvalidArgumentException: "Unable to find template "sisicalBundle:Index:index.html.twig"." at /var/www/web1261/html/sisical/vendor/symfony/symfony/src/Symfony/Bridge/Twig/TwigEngine.php line 133 {"exception":"[object]
I searched the hole src-folder in eclipse: none of my code uses 'Index' (with capital) any more (since I corrected this). Does symphony create sources in 'vendors...' when installing them via composer?
2) I think I don't use assets and they are not the problem.
3) As logs and cache are written, permissions seem to be OK.
4) Good idea, but I can't find an use. I use templating and for that no 'use'-imports for templates. Seaching for 'Index' I found the wrong template-name generated in the cache. Clearing and warming cache does not help.
Is it possible, that twig generates wrong when using Index as a package/folder name?
I debugged a little bit:
When warming the cache, the FilesystemLoader parses the file system... > works well. But when running with no cache, the template-engine uses the TemplateGuesser.php which calculates the foldername from the controllername. This one is capital, because it's from a class-name....
I now saw, that I use upper cases in my other project. This time I thought 'always lower cases is the easiest...'.
i have a serious problem in Magento Admin Backend. After login its shows a BLANK Page. i used the same files and database in different server, there it was working fine but when i have transferred files into LIVE then Admin issues came. Please help me over this as i got frustrated from last some dayz. If you need any more dertails then plz ask but i need to resolve this soon. Link: http://studywings.com/index.php/admin/
Magento ver: 1.7
flush your magento root /var/cache folder and /var/session folders, It may have previous server session that may cause problems.
Otherwise disable all third party modules and try again. I think this will help
I had the Same problem,
i have also debug the any errors occured, i tried index.php file
ini_set('display_errors', 1);
error_reporting(E_ALL);
$_SERVER['MAGE_IS_DEVELOPER_MODE'] = true;
pleced above code in index.php file. after that i have tried admin login.
showing the errors are session related, header already send errors.
i have to add the code in root/index.php file in top add the following line.
ob_start();
after that tried the login its worked.
Cheers..!
Is url changes to this after click login button or not?
http://yourdomain.com/index.php/admin/index/index/key/(key value)/
if url changes but not not show the dashboard page then go to
app/code/core/Mage/Core/Model/Session/Abstract/Varien.php
make copy of this file
Find the code for setting session cookie parameters these started on line 77
Comment out the final three lines and be sure to remove the comma after $this->getCookie()->getPath(). You should end up with this:
// set session cookie params
session_set_cookie_params(
$this->getCookie()->getLifetime(),
$this->getCookie()->getPath()
// $this->getCookie()->getDomain(),
// $this->getCookie()->isSecure(),
// $this->getCookie()->getHttponly()
also line 104 comment out :
//call_user_func_array('session_set_cookie_params', $cookieParams);
If there is no change in url after click login then try to uncomment display error and see error_log file of your server
I think this problem is due to file permissions. As you added files from one server to another, permissions might be get changed.. Try to give the permissions to all the files. Check this http://www.mage-shop.com/forum/threads/3-Magento-Admin-Backend-Blank-Page-Error
There are a number of things that can cause it, but it's most common after migrating to a new server, last time it happened to me it was an excessively low php memory_limit setting on the new server - the Admin part of the site uses a lot more resources per user than the frontend.
In general when having this issue:
Flush out your cache by emptying var/cache
Clear out sessions by emptying var/sessions
Check the magento error logs/reports for an error code in var\logs and var/reports
Turn on magento error logs in mysql if logging isn't already on! (look in core_config_data for WHERE path like 'dev/log/active'
Check if your php configuration is displaying errors
Check your apache/php error logs for more clues - memory errors will show up here for example
Try this solution
It sounds like you want to enable Developer mode. Add this to your .htaccess file:
SetEnv MAGE_IS_DEVELOPER_MODE "true"
You may also want to enable display errors in index.php:
ini_set('display_errors', 1);
The best way I have found to debug is with X-Debug in a local environment. You can also use log files to help debug in a production environment, if your unable to run X-Debug in the environment.
I've got a more detailed posting here:
http://www.molotovbliss.com/debugging-tips-and-tricks-with-magento-commerce
Consider also installing XDebug
Hope this helps you!
Just to complete the other answers....
I am upgrading a magento install, and got the same problem, in the end I had another folder inside of var/
magento/var/minifycache
Only worked after clear deleting the files inside of this folder.
I had the same problem after uninstalling an extension. I thought that clearing cache would be enough, and I did without success... later speaking with the technical team, they commented me that it did not work because I hace memcache installed, and needed to be done the cleaning via system - backend (that i coudl not see...)
None of out programmers has changed anything to the code, but out of nothing now, when a user tries to login on the backend, we have this error:
Fatal error: Call to a member function children() on a non-object in
/home/r1tech/public_html/app/code/core/Mage/Admin/Model/User.php on
line 437
Any ideas why this is happening?
Not a real Magento problem.
Somehow the files got corrupted. I re-uploaded everything and now it works just fine.
Leaving this for the occasional googler with this issue:
We had this problem today, after we had tested different caching mechanisms for Magento. In the process, the file cache directory was somehow corrupted or otherwise made unusable. If you're not keen on reuploading the entire thing as Beto Frega suggests, you should be able to solve it by removing (or renaming) the var/cache (in the Magento webroot, not the server itself!!) directory and creating a new one, which you then obviously give write permissions to.
This solved the issue for us -- and incidentally also some performance issues in the backend, due to the sheer size of the old cache dir.
CodeIgniter 2.0.2 syntax error blank page
i have CodeIgniter 2.0.2 (CI) and its annoing, that when i write lots of code and then just get blank page. Hard to debug without error. i got error reporting E_ALL in php.ini and in config of CI its turned on for every case of enviroment (devel, product) just for sure...
Does anyone knows, where the bug can be? How to turn it on? I think CI is rewriting php.ini error reporting setting somewhere somehow...
Thanks.
The other thing to check in your php.ini are the 'display_errors' and 'display_startup_errors' variables, they should both be set to 1.
In my (little) experience with CI this issue has been the most frustating one. I can understand that no framework is perfect, and any web developer is used to deal with errors (no matter if the framework or the developer is to blame). But that ANY error results in a blank page, with ZERO information in logs, console, whatever, is unacceptable.
If I recall correctly, in my case this was caused by of some combination of CI (ab)using the "silent error" PHP operator (e.g. prepending some db statements with the # operator, a not very clever way of avoiding leaking potentially private information to the end user), together with some bad use of *error_reporting*. See my post here (and see how many answers I got!).
I reported another related CI's idiocyidiosyncrasy related with logging here (again, zero answers)
please check the index.php which locate in the SAME LEVEL of the application folder
inside the index.php the second line
line 2:
ini_set("display_errors", "1"); //ensure it is set to 1
line 23:
define('ENVIRONMENT', 'development'); // development | testing | production
grep your php.ini for the word "error", turn them to On etc...
Do you have output compression turned on in the config? I find that will cause white pages when you have errors.
$config['compress_output'] = FALSE; // Should be set to this when developing.
I had the same problem and eventually fixed it when i noticed I had no 'logs' directory in my application folder