search

craftcms / cms

Build bespoke content experiences with Craft.
https://craftcms.com
Other
3.28k stars 635 forks source link

[4.x]: While creating a Matrix field, the "New block type" button does not work anymore #12317

Open azad6026 opened 1 year ago

azad6026 commented 1 year ago

What happened?

Description

Steps to reproduce

  1. Create a field and select "Matrix" type
  2. Click on the "New block type"
  3. It does not do anything

Expected behavior

  1. Create a field and select "Matrix" type
  2. Click on the "New block type"
  3. It should pop up a box to add your block type as usual

Actual behavior

  1. Create a field and select "Matrix" type
  2. Click on the "New block type"
  3. It does not do anything/no error in console as well

Craft CMS version

4.3.1

PHP version

8.1.12

Operating system and version

MAC Monteray 12.6

Database type and version

Mysql

Image driver and version

No response

Installed plugins and versions

-

brandonkelly commented 1 year ago

It’s working on my end. We have seen the same report though (#11657). In that case it ended up being because config/app.php was overriding the view component config incorrectly. See https://github.com/craftcms/cms/issues/11657#issuecomment-1259676111 for the explanation, in case that’s the same issue here.

azad6026 commented 1 year ago

Thanks for the reply @brandonkelly ,But we don't have the custom view settings in app.php butI tried that solution and read the bugs mentioned but it didn't make any difference. I have noticed it is not only happening with Matrix fields but also with Neo fields. any tips?

brandonkelly commented 1 year ago

If you have your JavaScript console open, and then go to the field settings page, do you see any JavaScript errors getting logged, either before or after you try pressing “New block type”?

pierrestoffe commented 1 year ago

@brandonkelly I was able to replicate this issue on multiple Craft CMS instances running on multiple versions of Craft CMS 3.x, including the latest one 3.8.6. I also found another clue that should help you replicate the issue in a local environment.

In this first video you'll see that creating a new field and changing the field type to Table or Matrix returns errors in the console, but the functionality doesn't break. I'm still able to add blocks in my Matrix field.

https://user-images.githubusercontent.com/1706605/230073003-a6f397d1-08ba-4c0b-a7bf-2e396f3cec3a.mp4

In this second video I'm running the CMS on a subdomain (admin.website.com) while the website runs on website.com. So the value of baseCpUrl in config/general.php is different from the Base URL of my main Site. Here we see that the console doesn't report a 404 but a JS issue instead. This issue then prevents me from adding any block.

https://user-images.githubusercontent.com/1706605/230073078-5d64fc4c-6b05-4e25-8bff-8c721436cfff.mp4

Note that if I save the new Matrix field without adding any Block and the page reloads, I'm then able to add a Block. Probably because at that point the page loads with the field type already set to Matrix.

Also, on that same CMS instance, when I switch the baseCpUrl to the same value as the Base URL of my main Site, I'm back to the issue displayed in the first video. So this seems to indicate that the issue affects everyone, but only has negative consequences when the CP URL is different from the main Site URL.

Let me know if you need more info.

brandonkelly commented 1 year ago

This sounds a lot like #11657, where the issue ended up being due to a misconfigured view component in config/app.php. See the solution here: https://github.com/craftcms/cms/issues/11657#issuecomment-1259676111

pierrestoffe commented 1 year ago

@brandonkelly Oh, I forgot to mention that I had indeed tested that solution. I went as far as removing everything in config/app.php, removing everything but baseCpUrl in config/general.php, and only requiring "craftcms/cms": "3.8.1" and "vlucas/phpdotenv": "^5.4.0" in composer.json. This didn't make a difference, the above was still happening.

It's happening in local environments (created with ddev, tested with both nginx and apache) and prod environments, using a proxy and without a proxy. But once again only when the CP is running on a different (sub)domain.

brandonkelly commented 1 year ago

Are you overriding the resourceBaseUrl setting in config/general.php?

pierrestoffe commented 1 year ago

No, I don't use that setting, and still encounter the issue when the only value that I set in config/general.php is for baseCpUrl

brandonkelly commented 1 year ago

Try opening your browser’s Network tab, then reloading the field settings page. Are you getting any 404s for the JavaScript resources?

pierrestoffe commented 1 year ago

@brandonkelly Not as soon as I reload the field setting page as the default field type is "Plain text", but as soon as I switch to "Matrix" then yes I do get the same 404 and JS errors as shown in the videos above.

A new client gave me access to their existing CMS instance and repo this morning and I immediately tested creating a new Matrix field with their setup → same thing happened.

Just to be sure, I then tested the scenario on a fresh Craft install:

  1. Followed the 4 quick start steps listed here. Set the domain name to temp.ddev.site
  2. Added ->baseCpUrl('https://admin.temp.ddev.site') to config/general.php
  3. Logged into the CP, clicked on the button to create a new field, same thing as explained above happened

Are you able to replicate the above on your end?

brandonkelly commented 1 year ago

No, I’m not able to reproduce.

Screenshot showing that a new Matrix’s field settings are working correctly with the above configuration.

No, I don't use that setting, and still encounter the issue when the only value that I set in config/general.php is for baseCpUrl

What about .env? Any CRAFT_* config setting overrides in there?

pierrestoffe commented 1 year ago

@brandonkelly Sorry I apparently made a mistake in the fresh install test I made as I re-tested and it's all working correctly there now.

Good news though: I took one of the projects I'm working on, removed every dispensable layer/setting one by one and eventually found what element was at the origin of the issue: the @web alias defined in config/general.php.

When I read a while ago in Utilities/System Report that we had to override the @web alias as a safety measure, I didn't think twice and set it to my BASE_URL env var. Its value is the URL of my project (https://www.project.com)… but not the subdomain used by the CP (https://admin.project.com). It turns out that @web apparently needs to be set to the CP base URL instead since the error disappeared as soon as I made the change.

I know what to do now, but could you just confirm that this is correct and I'm not potentially creating other issues by setting @web to the CP base URL please?

brandonkelly commented 1 year ago

Glad you’ve got it working! I had considered it could be a @web issue but you said there was nothing in config/general.php besides baseCpUrl, which ruled out aliases.

If you are using Craft headlessly, it’s safe to hardcode @web to the CP base URL only. If your front-end site is also running on Craft, then you could set it to / to cover both CP and front-end requests.

jrrdnx commented 1 year ago

I'm running into the same issue with Neo/Matrix fields, and am also using a subdomain for CP access so baseCpUrl is set to https://admin.domain.test and the @web alias is set to https://domain.test

Setting @web to either the CP base URL (as mentioned here) or / doesn't work for me, as the control panel is broken in both cases (returns the front-end for https://admin.domain.test or 404 for any other CP pages).