magento / magento2

Prior to making any Submission(s), you must sign an Adobe Contributor License Agreement, available here at: https://opensource.adobe.com/cla.html. All Submissions you make to Adobe Inc. and its affiliates, assigns and subsidiaries (collectively “Adobe”) are subject to the terms of the Adobe Contributor License Agreement.
http://www.magento.com
Open Software License 3.0
11.55k stars 9.32k forks source link

Upgrade to 2.1.7 causes CSS and JS directory issues leading to 403 errors #9821

Closed UKRogue closed 7 years ago

UKRogue commented 7 years ago

PHP version 5 - Process: Magento Upgrade from 2.1.5 to 2.1.7

Accessing Front End Store or Back End Admin after upgrade causes file not found issues as directory references appear to have been changed: example Now: http://mysite/pub/static/**version1496302859**/adminhtml/Magento/backend/en_GB/extjs/resources/css/ytheme-magento.css Should be: http://mysite/pub/static/adminhtml/Magento/backend/en_GB/extjs/resources/css/ytheme-magento.css

I have

  1. removed cached files in var folder, (var/di/ var/generation/ ....etc
  2. changed permissions to var and pub to 777,
  3. redeployed static files for en_GB and en_US,
  4. cleaned the cache,
  5. changed permissions to var and pub to 777 again also compiled and repeated above steps.

Upgrade was done via command prompt in Putty

As a result images, css and js fail to load causing a breakdown of the site. I have upgraded/redeployed static files several times before with no problems.

Any help greatly appreciated!

UKRogue commented 7 years ago

ok, i'm refering to https://github.com/magento/magento2/issues/6688 which is a similar issue, although i've not had this issue before so something must have changed.

UKRogue commented 7 years ago

Well unfortunately https://github.com/magento/magento2/issues/6688 did not help. Something must have changed since 2.1.5 to affect permissions/directories. I've upgraded 4 times with no problems. Version in directory is not the issue as 403 and 404 errors now refer to files with correct destinations. ie Failed to load resource: the server responded with a status of 404 (Not Found) /pub/static/adminhtml/Magento/backend/en_GB/extjs/resources/css/ext-all.css Failed to load resource: the server responded with a status of 403 (Forbidden) /pub/static/adminhtml/Magento/backend/en_GB/extjs/resources/css/ytheme-magento.css Failed to load resource: the server responded with a status of 403 (Forbidden) /pub/static/adminhtml/Magento/backend/en_GB/jquery/jstree/themes/default/style.css Failed to load resource: the server responded with a status of 403 (Forbidden) require.js Failed to load resource: the server responded with a status of 403 (Forbidden) mixins.js Failed to load resource: the server responded with a status of 404 (Not Found)

Owner of file is correct and permissions are 777 and .htaccess files have not been changed since it was working on 2.1.5. Can anyone cast light on this?

southerncomputer commented 7 years ago

redis-cli -p 6379 flushall redis-cli -p 6380 flushall

Seems to help when php bin/magento cache:clean doesn't help!

I do know what you are talking bout! I have quote.min.js being required from the wrong directory and 404'ing. Something must have changed as far as require-js since 2.1.2 - everything works in developer mode but deploying with php bin/magento setup:di:compile then php/bin magento setup:static-content:deploy -j 1

note -j 1 is required if you use redis! still fails to move the custom quote.min.js to the right pub/static directory!

I found that in development mode, all works okay, but when you deploy static-content - it loses track of require dependencies that use relative paths. Which causes missing javascript when trying to load a page, extraneous missing javascript calls.

Have to check for require in *.js for use of './quote' or '../model/quote' and return to normal full pathing like 'Magento_Checkout/js/model/quote' but not specifically for quote - that was my case,

southerncomputer commented 7 years ago

https://github.com/magento/magento2/commit/b9ddac74c71df89e920c8f62fa59dbf3b0ddc083 change default_jobs_amount =1 to fix redis and static-content:deploy issue!

UKRogue commented 7 years ago

Pretty sure my issue is permissions related. Somehow doing the upgrade has upset things. Its requesting the correct file in the correct directory but can't access it. I'm looking at groups, root and user permissions currently to see if i can identify whats changed.

gopal2k6 commented 7 years ago

I did fresh installation in my localhost and same issue found.

Regards Gopal Gautam

buskamuza commented 7 years ago

@UKRogue , did you check Apache logs? Maybe there are some hints there. As you have 777 on all the files, it's strange that you don't have access. The only thing I can think about is that one of the parent folders (pub or Magento root) still has wrong permissions. When doing upgrade from command line, ensure you use either the same user as Apache/php or user in the same group, so Apache can access the files after the upgrade. Also, which Magento mode do you run?

buskamuza commented 7 years ago

@gopal2k6 , do you use Apache or Nginx? Which Magento mode do you use? Do you also have both 404 and 403? Which specific issue do you have: have version added to the links and files are not accesible or files are not accessible even after disabling the versioning?

gopal2k6 commented 7 years ago

@buskamuza I am using Apache and i am using Just simple Magento installation. and got versionxxxxxxx 404 issue.

buskamuza commented 7 years ago

Is https://httpd.apache.org/docs/2.4/mod/core.html#allowoverride working for Magento folder (especially pub/static)? Did you look at Apache logs? Maybe there are more errors there. In general, it looks like .htaccess is not read properly by Apache, so it can't handle this versioning.

UKRogue commented 7 years ago

Thanks for your responses. Unfortunately my service provider temporarily lost my site during backup restore for the last 5 days. I had to restore from backup as my attempts to ensure folder/file ownership and permissions were correct caused a cpanel malfunction. (Ensure you are in correct folder before changing permissions lol!!!) However, the site is up and running now at 2.1.7 revision with no apparent issues. To answer some of the questions and suggestions:

  1. I was upgrading to 2.1.7 from 2.1.5
  2. I was upgrading from an account in shell (not root) that "appeared" to have the correct folder and file permissions and was in the correct group.
  3. When i originally installed Magento I did this from root and changed permissions and ownership retrospectively. This was due to ignorance at the time.
  4. I am running on apache with php 5 and mysql.
  5. Logs showed no new errors that i did not expect to see.

Summary: In essence I believe that if my initial installation had been done with the correct ownership and folder/file permissions, I would not have had this problem now. However, it is odd that I have upgraded several times previously and not had an issue.

buskamuza commented 7 years ago

@UKRogue , thanks for your response. Yeah... it's hard to say what was that.

lilu-box commented 7 years ago

I have the same issue with Some images on my site (in particularly with logo which I'm trying to change). And the weird thing is that i get 404 Page not found just for some files from the same folder in which there are also files with the same permissions which i can see without any problem. I've tried all possible solutions which i could find - nothing. It came to my attention in Media Storage, where some images are perfectly loaded, while some of them look nonexistent.

Cruiser13 commented 7 years ago

I got the same issue, some JS and CSS files are simply not loaded in front- and backend due to 403 errors after updating to 2.1.8. The 403 errors disappear when switching to development mode.

magento-engcom-team commented 7 years ago

@Cruiser13 In production mode static files are not generated in runtime. This only happens in developer mode, so looks like behavior is correct.

magento-engcom-team commented 7 years ago

@UKRogue we are closing this issue due to inactivity. If you'd like to update it, please reopen the issue.