Firstly I know how to deploy and work with files, I don't need answers saying 'redeploy static content' or 'clean cache' - experience from the research.
We having an issue on our development server. We have tested it with multiple projects, versions vary from 2.1.5 to the 2.2.3 open source.
After steps below we are receiving random 400 errors on some files (1-10 files). All those files are .js.
FUN PART:
After trying to get that file again (open in new tab) - everything is working fine, file is there, nothing bad.
After trying hard refresh again - again errors, but on other files.
After multiple soft refreshes (F5) - it looks good again.
Deployment mode - Developer
Steps to reproduce
Install Magento without Sample date (tested with 2.2.3) - nothing configured.
Set deployment mode Developer
Deploy static content or just clean /pub/static/
Chrome/Firefox - Inspector->Network tab->Disable cache (CHECKED)
Clear site data on the browser.
Create a product - for testing.
Go to the website and then to the product (no errors even after hard refresh).
Add product to the cart. (no errors even after hard refresh).
Go for example to the category. (errors even after hard refresh).
After clearing site data - everything looks fine again.
We have reproduced this on multiple pc's / webbrowsers.
Server info:
PHP: 7.1.16
APACHE: 2.4.33
DirectAdmin 1.52.0
Debian: 8
Any suggestion what to do or what to check/change will be useful (except a stupid ones, no one likes those)
P.S. I was not sure if I should post it here or magento.stackexchange.com
Or if I can post on both websites at the same time.
Good morning all
After all we have found an issue. It was an apache module : mod_ruid2
After it was disabled - no more random 400 errors has appeared.
I hope this anwer will help someone even if this is an uncommon issue.
To turn the module off, you need to do the following steps in the command line:
cd /usr/local/directadmin/custombuild
./build set mod_ruid2 no
./build apache
Related
I've been developing a website built on OctoberCMS, using the Laravel Homestead vagrant box as my local development server and have so far been getting along swimmingly. I developed most of a theme this way.
However I've recently started running into a problem wherein requests for assets/vendor.css in the theme assets succeed but receive a text/html response containing HTML for the homepage instead of the proper CSS.
This means vendor CSS for the page doesn't load. However if you repeat the request for vendor.css with "open in new tab" after page load the correct asset is returned, and the Chrome 'sources' tab also shows the correct asset.
This strange behaviour seems to extend to JS assets. I'm currently looking at a request for assets/vendor/jquery.js where the inital response actually contains the contents of assets/theme.css - and this is causing JS errors in the console.
In this case however if I make the request to that URL again I actually still receive the same incorrect CSS, but once again the Chrome 'sources' tab actually shows the correct asset.
Inspecting the files in my code editor I see the correct assets under the correct filenames and locations.
It seems I might have an issue with Homestead's web server. However I'm confused about where it might have come from as I haven't reconfigured anything and this has been working fine previously.
I've confirmed that the problem still persists even after deleting the homestead VM, and then building a brand new one and installing a fresh copy of OctoberCMS, without importing any of my own custom theme files.
I tried having a look into the nginx logs on the VM to see if I could spot anything odd, but it looks like they all have no content, 0 lines.
I'm a bit stumped and haven't found much helpful searching around.
Any suggestions? Help much appreciated.
So I've managed to re-build my project in such a way that this time I didn't reproduce the problem.
I'm pretty sure that ultimately it was caused by the fact that I relocated the homestead VM (and projects therein) by renaming its containing folder.
In previous attempts I had been deleting the VM by running vagrant destroy and then re-creating it by running vagrant up.
Once I completely deleted the homestead repository and re-cloned it from scratch from laravel/homstead on github, then proceeeded to vagrant up and set up OctoberCMS, I no longer experienced the issue.
I suspect perhaps the original path to my VM (before rename) was still in a configuration file somewhere in the laravel/homestead project and the disconnect between this value and the actual filepath was causing the problem.
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 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. :]
I'm working on a WordPress installation hosted by HostGator. I have added new code to a php file which is used for the home page gallery slider. The changes work on my local installation but do not appear on the live site. I have even attempted to insert gibberish code into the file to see if it would update, It did not. This leads me to believe it's being cached somewhere and not updating.
I have disabled all suspected caching plugins.
Added define('DISABLE_CACHE', true); to wp-config.php
Cleared all browser caches, and CTR + F5
Verified the code is sound
Waited overnight to see if it would update eventually
STATUS UPDATE:
I've continued to do the steps I've outlined above. I've had suggestions that it may not be the correct file that I am editing. The problem with that assumption, is that it works fine on the local host test site, just not on the live. If anyone has suggestions in that regard it would be helpful as well.
UPDATE 2:
I'm attempting to determine if my Instant Wordpress 4.3.1 runs a different php version than HostGator (php 5.2.17) but I can't find it in the documentation.
I was using Magento 1.4.1 and upgrade gracefully to 1.4.2. After testing if the upgrade was Ok, I made some modification in order to have a new home page layout for a store using these instruction. The modifications have been tested on a local version (Ubuntu 10.04, php 5.3.2), and worked great.
When I upload the files to the pre-prod server (Centos 5.5, php 5.2.14), and access the System->Configuration->design tab in the admin backend, my browser seems to keep loading indefinitly.
What I have done:
I copied the app/code/core/Mage/Page/* directory to the app/code/local/Mage/Page/;
I created the app/etc/modules/Mage_Page.xml, and defined the codePool to local;
What I have already checked:
I got no errors in /var/log/httpd/*.log;
I got no errors in magento's var/log/system.log;
The frontend works fine;
The backend can be accessed, except the System->Configuration->design tab;
I tried to revert my modifications to a revision before the modification were made (using svn);
I cleaned up the cache using rm -fr var/cache/mage* var/session/* directly on the server;
I restarted the server multiple time;
I even tried to get a dump of the db in production on the preprod server, with no effect. I still got the same issue.
If someone could point out anything I could have forgot.
I am ready to try anything to make it work, since it would not affect the production server for now.
After a lot of searching, we finally tried to reboot the apache server (we had to force it to reboot, I don't know why?). When we retried, everything was working as expected.
There probably was a corruption on the server that made crash only this tag.
Hope this could help someone.