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.
Related
I have a functioning laravel app that I developed locally. I moved it onto a server via ftp (just to show someone for feedback).
I changed the APP_URL in .env to the subdomain pointing to the /public folder. Also changed the database information. Everything else was left exactly as is.
I can access the front page without any problem. Anything else (e.g. /login or an AJAX to any other controller) results in a Server Error 500 that leaves no trace in the server error logs.
When I assign different routes to the / those are also displayed. I can show pages that pull data from the database, so that is not the issue.
Both local development and server run apache on linux.
Any pointers?
Update: Thank you for the suggestions so far. I currently cannot access the server via ssh (not my server). I'm working on getting that set up and will try your solutions as soon as I can.
Thanks everyone.
With a little help from the hosting company we found the problem. All we had to was to add
RewriteBase /
to the .htaccess automatically created by laravel.
Make sure that your web-server has read and write permissions to the following folders
public
bootstrap/cache
storage
If the web-server does not have these permissions it cannot compile views, store session data, write to log files or store uploaded files.
Set Webserver as owner:
assuming www-data is your webserver user.
sudo chown -R www-data:www-data /path/to/directory
Not always will work if you CHOWN it, in some cases I had to CHGRP to www-data on my Ubuntu VPS as well.
How I'm checking is this:
Domain has to point and if there's an SSL, a padlock in the web browser has to be seen. No matter on your localhost, but Laragon is the quickest to set it up.
Now I know that I see what I should if I can write something in my index.html file inside. If I can't see it, permissions or roles are wrongly set.
Laravel has tons of info online (or google it) on how to set up CHOWN and CHGRP, so, if I'll clone some repo, or unzip it, the first thing now is to set these two up. If these two are rightly done, I can do npm install, composer install - if it's not a shared hosting where I can't do it, but VPS or localhost.
Now you should be able to see Laravel's pages and only public and storage might want different permissions than the rest.
.env file should be created with right permissions as well, if no, you won't key:generate later for instance.
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!
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 have google's pagespeed installed with nginx server installed following here. I need to flush/delete the previous cached content but could not find a solution. On pagespeed site its mentioned to use this command:
touch /var/ngx_pagespeed_cache/cache.flush
But I have no success with it. Thanks for any help.
try this click here for more
sudo touch /var/cache/mod_pagespeed/cache.flush
Is /var/ngx_pagespeed_cache your caching folder? If so, this should work. As Dayo noted, we do not delete the files, just invalidate them.
However you can also just rm -r the caching folder and then reload Nginx (to clear the in-memory cache). If you are using memcached, you'd have to clear that too.
My Joomla 2.5.4 site was cracked last night. Moreover, the Joomla forum is currently down, and I can't even run Joomla's diagnostic utility. (fpa-en.php)
I have followed Joomla's instructions for diagnosis with no success. (See below) I have also emailed my webhost (I am on a shared server, but I use a host recommended by Joomla that is a specialist in Joomla sites). So, my question is what do I do next?
Here is the info that I have so far.
Using Joomla 2.54 (the latest). All extension were updated to most recent release, and none are on the Joomla vulnerable extensions list.
Passwords of other administrators were changed but not mine fortunately.
User_notes table deleted, which renders the User Manager in the admin section useless.
According to logs the attack hit the following files in this sequence:
/administrator/index.php
/index.php (Root)
/plugins/authentication/joomla/joomla.php
/plugins/user/joomla/joomla.php
and then the changes to the users and user_notes tables.
There is no junk in either index.php
Attack ip was 199.15.234.216, which is from a Fort Worth server of supremetelecom.com
Fortunately, I have backups and there was no defacement, but until I can't get fpa-en.php to work and access to the Joomla forums, I am not sure what to d0 other than change all passwords and block the ip.
Thanks in advance for any help!
Firstly, reset the passwords of all the administrators, including yours, then change them and ensure they include letters and numbers. Then change the password for the host control panel using the password generator if they provide one. If not, use a password generator online. Once this is done change the password for your database username and don't forget to also update the configuration.php with your new password.
Secondly, download and install Admin Tools which will add more security to your site for the future. Admin Tools also comes with an Emergency Offline button which is useful.
Then download and install Saxum IP Logger which will trace all the registered users, giving you their IP address, country and so on and you can also block IP addresses using the plugin that comes with it.
Next, go to the host control panel and look at the logs to see which IP addresses have entered your website and while files they have accessed. The IP address that coresponds to the files edited, you can then block using the plugin I mentioned before. Joomla 2.5 is very hard to hack so it is rather likely you have an extension that is badly developed and allows SQL injection. Therefore you should always choose popular extensions to install on your website when they are database related.
Hope this helps you in the future. Regards
EDIT : You can also password protect your folders in the FTP for additional security.
You may also find this extension quite useful
After you recover from this, make sure you place a password on the /administrator directory with .htaccess, assuming this is a Linux based server.
Couple of steps that will help you identify the point of access.
Also depends on if you have access to some server side tools.
Contact host and ask them if they run Mod_Sec if so ask them for the Mod_sec flag for that IP.
Ask the host if they run any type of maldet tools - if so ask for a scan of your account.
If you have shell access run a check on what were the most recent files changes... Side from tmp and cache files.
Fixing the hack
1. Change all your passwords -
2. Install project honey pot.
3. Admin tools install is good but you need the pro version to really gain access to the security tools.
4. Migrate to a host that specializes in Joomla platforms, in most cases they already have the accounts configured for common security issues in Joomla.
Getting hacked really sucks... Good luck!
Relocate your administrator page by editing the config.php files .. and edit your FTP permission settings. If your administration login url was the standard location. (www.site.com/administrator ) change this location and block access using your hosting control panel to only certain ip address (and even restrict access by hours of availability.
How many administrator user accounts do you have. There really should be only one person with super user access . It is really not productive or safe to have other users that do minor edits of the website with administrator privileges; and they could accidentally cause issues. These are basic steps and there is a lot more you can do. Send an email if you need help/step by step instructions. Hope all goes well.