I have downloaded Magento in combination with DevBox to build my webshop locally. After installation with the terminal, I got the url to the shop and the admin (something like: http://127.0.0.1:32769/ and http://127.0.0.1:32769/admin/).
This all worked great! But then I stopped to continue some other time and stopped the working-container with the commandline.
When I wanted to continue, I started the working container and it now runs on another port. However, on this port only the HTML is loaded.
The system tries to download the rest of the files on the old port (:32769), which is obviously not working. Stuck here!
It's hard to say without seeing your system (not super familiar with the devbox), but regarding
The system tries to download the rest of the files on the old port (:32769), wich is obviously not working. Stuck here!
It sounds like the URLs generated in your source might be cached from the previous session. This means they have the old port number. If you clear your system's cache store, that should solve the problem.
I'm not 100% sure if the dev box ships with redis as a cache store, or the file system, varnish, or something else. It depends on the options you chose. The first thing I'd try is running Magento's cache clean command from the command line
php bin/magento cache:clean
The next thing I'd try is removing the var/cache/* folders. If you're using varnish or redis you'll need to research how to manually clear those caches. Hope that helps!
Related
I am currently maintaining a Laravel 5.5 project.
I have a copy from the production that runs on my own computer. Both of the session drivers I use are File.
Recently, I found that the production started unable to save/store any file in the storage/framework/sessions folder.
However, no matter how I change the permission of all the folders inside storage folder to 777, session files just don't appear in the storage/framework/sessions folder, while the copy that runs on my own computer just writes files as usual.
I can't figure out how the problems would be, even search every information I could find, the problem still can't be solved.
Also, I'm not sure what information that is helpful for others to inspect. The only one that might be helpful maybe the host I use of the production is Hostgator.
Oh, I found the problem was at the .env file, the one in the production was modified by someone or occasionally to use cookie as its session driver.
I've neglected this part, while config/session.php didn't have any differences between the two environments.
After I set the session driver into file and ran php artisan config:cache, everything started performing correctly.
My problem is that I do not think I am able to refresh the magento redis cache from the admin page. I realize that the problem could come from many sources, but my gut tells me it has something to do with the backend being on a separate server. My magento installation is as follows:
Magento CE 1.8
Backend server and NFS(media) on an Amazon AWS EC2 at
http://admin.example.com
Database on AWS RDS MySQL 2 app servers
(scalable to more) on AWS Elastic Beanstalk at http://www.example.com
(route53)
regular backend cache(database 0), Lesti-FPC(database 0), and
redis_session (database 1) on AWS elasticache redis
I originally had my Lesti-FPC configured to use database 2 on the redis cache. I thought it worked pretty well as far as I could tell, until I realized that I couldn't flush the cache at all from the admin System>Cache Management page. "Flush Magento Cache," "Flush Cache Storage," "disable", and "refresh" did nothing. I could only flush it by rebooting the redis node or going in with redis-cli and using redis commands.
I then tried configuring Lesti-FPC to use database 0 as described above. It worked better. Now, I could flush the FPC with "Flush Cache Storage," although the other options still didn't work. At the time, I assumed it was an issue specifically with Lesti-FPC. But anyway, using "Flush Cache Storage" was good enough for me at the time, especially once I discovered that I could flush the cache through code using
Mage::app()->getCacheInstance()->flush();
I just recently found out that the problem may not be specific to Lesti-FPC. While trying to fix the Lesti issue, I tried monitoring redis. I know nothing about redis or caching, but when I would try to refresh the FPC, I would see commands like:
“del” “zc:ti:403_FPC”
“srem” “zc:tags” “403_FPC”
But those tags never existed. Doing:
keys *FPC*
in redis would give me
“zc:ti:109_FPC”
but nothing with 403. SO this means that my fpc caches do not get invalidated like they're supposed to after product/category changes and reindexing. I got around this by manually flushing the cache after changes and running cron jobs to flush and prime the fpc every few hours.
But it made me suspicious. I tried refreshing the other caches from the admin, and I found that magento would always try to delete and read the 403 keys(some of which existed and some of which did not) but never any 109 keys (of which there are many).
My guess is that the 403 keys are specific to the admin server, and the 109 keys are specific to the app servers. The admin server, maybe because it is on a different subdomain, is not touching the app servers' cached stuff. But the app servers are able to find its own keys fine, as demonstrated by the fact that the FPC is working very well.
Does this make sense? Is there something I could do to fix this? Did I configure something incorrectly or is this a magento bug?
It turns out that the Zend cache prefix is the first three characters of an md5 hash of the path to your etc folder.
My app server has its document root at /var/www/html. The full path of /var/www/html/app/etc gives an id of 403. The app servers running on elastic beanstalk have their document roots at /var/app/current which is done automatically at deployment.
It seems pretty dumb. Why not a hash of the database address and database name or something? That would make more sense.
Anyway, I hope this helps someone.
I built my site on my local machine on MAMP and I migrated the finished site to my remote server. I used Akeeba Backup and Kickstart and installed before making the final back up and then setting it up on the remote server.
However after doing so, I am no longer able to login to my admin. The passwords have not changed and the only thing I get is a yellow pop up message above the login box that says "Warning".
I reset my passwords several times but no success. The site works without a hitch so I don't think something went wrong on the migration but that wouldn't explain why I no longer can't log into my local instance.
I am a little perplexed. I am not sure if there is a bug with Akeeba Kickstart 3.9.
Most probably your remote server has the newer PHP version. The reason is that new PHP version generates the MD5 in a different way.
I also had the same issue once ... please try the following steps...
in you DB's Joomla user table
Backup the password'hash of your desired user.
Now go to this site and get the new MD5 hash of your password.
INSERT the new MD5 hash into DB.
Now try logging in again.
I found my issue even though my local MAMP was using PHP 5.3 and my remote server PHP 5.6 the actual problem was that for some reason the Joomla User plug in was disabled during the migration which caused me not being able to log in.
I went into my DB and set the flag from '0' to '1' and it resolved the issue. I am not sure how the parameter was changed but it was the culprit.
After i pull changes from development server to production server the styles and scripts are
not loading up in the html as shown below
I tried restarting the server and php service and cleared the caceh under /var/cache folder.
what i am guessing is its because of Cache, but i cannot disable cache under admin panel as all the scripts are not added to head.
how do i disable all cache in this scenario?
Please suggest.
If you have SSH access, go to var/cache/ and rm -rf. I wrote a php script to do exactly that, too, so my staff doesn't have to use SSH when an extension's developer tells us to "manually delete all the cache".
I think you can refresh the Cache in the Admin; dont have to disable, if you are not allowed.
Also, please clear the browser cache.
Three main caches, besides from any other 3rd party cache package you might have installed, its best practise to clear
var/cache
Magento Admin =>System->Cache Management(Refresh the cache based on your requirement).
Browser cache
Cheers,
Swapna
I have fixed the issue, i did the below things
1) Removed var/cache
2) Restarted my web server and php service
3) Disabled my compiler path through shell
and it worked just like that.
I tried to deploy my project with capifony, becouse I found here an answer, that with capifony deployment is easy. Well I don't think it is, so my question is:
How can I deploy my project via ftp, I put all my files on the server but even if I browse to web/app.php, the only thing I get is an empty page, whatever route I write in the url. So someone please explain me how can I get this work! Thank you!
A couple of things to think of when deploying a Symfony2 project to a new server or computer (as far as I've encountered) might be:
Make sure that the server and it's PHP installation meets the Symfony2 requirements (and perhaps also the recommendations)
Check that you've somewhat followed the installation instructions (found here)
Try to clear the cache
Make sure that the web server and it's PHP process have write permissions to the cache folder
If none of these helps, try to modify the app_dev.php to temporarily allow access from your current (client) IP (instead of restraining it to localhost). Then, hopefully, you'll get a more useful and detailed error message, instead of the blank page (which often is caused by some fatal error that have occurred during the initialization of the framework and its kernel)
Update: Noticed now that you've tagged your question with 'windows', but that you don't mention which server you're trying to deploy to. I wrote the above with some *nix based server in mind, but hopefully some of it are applicable to Windows servers too (but there might be other common sources of error running under Windows that I'm not familliar with