Content management does not offer markdown editor anymore

[Bobby-Amali]

Which Specific Feature is your question related to?

Content Manager

Question

My amplify blog project works very much around your markdown editor and now I cannot make any new posts because for some reason there is no support for the markdown editor again I can't even move to the next line when inputting data

[ykethan]

Hey @Bobby-Amali, thank you for reaching out. Wanted to get some additional information on this issue.
could you provide us your schema being utilized, additionally screenshots/screen capture would help us in diving deeper.

Furthermore, as a mitigation step Amplify Studio does allow switching to the older version of the Data manager. We can do this by replacing the URL path from /data-manager to /content.

[ykethan]

Tested this in my Amplify Studio Data manager, the markdown option does not appear on record. Marking as bug.

[Bobby-Amali]

Hey @Bobby-Amali, thank you for reaching out. Wanted to get some additional information on this issue. could you provide us your schema being utilized, additionally screenshots/screen capture would help us in diving deeper.

Furthermore, as a mitigation step Amplify Studio does allow switching to the older version of the Data manager. We can do this by replacing the URL path from /data-manager to /content.

Thanks a lot for this fix, I'll keep using it while I wait for the bug to be fixed on the new data manager

[JCKalt]

I also had this problem. Switching to /content fixed the problem for me as well. I had no idea this option was available. it seems now when I select the Content tab it goes to /data-manager instead of /content.

[Huetarded]

Switching to /content worked for me and, thankfully, will save my weekend!

There are, however, some related issues to the original bug that are worth calling out. There seem to be a few things that got messed up with this "Data Manager" update.

1. In my current project, which was created and populated with data before this update, data no longer shows in form fields when you try to edit an entry under "Data Manager". When switching to /content and opening the same record, the data is all there and can be edited as expected. Shown below is the new form and the same record in the old form.

2. Custom data type fields now show up as single text fields instead of multiple fields that would represent the structure of the custom type. Shown below is the new form and the same record in the old form.

[abhi7cr]

Hi @Huetarded, thanks for reporting!

For 1) Can you open the console and see if there are any error/warning logs that might be preventing the details of the record from showing up in Data manager ?
For 2) Currently, custom types are translated as plaintext fields which accepts the json shape configured. We are working on improving the experience of custom types.

Thanks for you patience!

[Huetarded]

For 1) Can you open the console and see if there are any error/warning logs that might be preventing the details of the record from showing up in Data manager ?

Hi @abhi7cr - Yes, I am seeing the following error...

26.13534352.chunk.js:2 [Report Only] Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self' https://d1fqdzidq79abj.cloudfront.net https://*.amplifyapp.com https://prod.pa.cdn.uis.awsstatic.com https://*.cdn.uis.awsstatic.com/ https://*.cdn.console.awsstatic.com/".

[Huetarded]

@abhi7cr - Any update on this bug? Switching to /content is pretty straightforward for me, as the developer...but it's not very convincing to my clients, who are wondering why it's broken and now requires a wonky workaround when they previously had a fully functioning interface before the update. I tried to cover and say "oh, there was just an issue with the update and they will release a fix very soon" but now it's been weeks and I'm like WTF? 🤷🏼‍♂️

I know you previously mentioned you guys are trying to improve the experience, but doesn't that typically mean leaving what's already functional in place while the improvements are being developed? I mean, we went backwards here and it's becoming frustrating for myself and my clients 🤷🏼‍♂️

[thomasbosviel]

Hi @abhi7cr, I have the same issue with my clients. They are upset about this Amplify Studio update, as they don't understand why retro-compatibility wasn't ensured for editing custom field types. Switching to /content is not a sustainable solution for them.

On my end, I'm concerned that access to the old content manager (/content) will be closed in the near future without the editing functionalities being restored. #826 has been labeled as a feature request!

Should we anticipate a modification of our data models (based on relationships) to work around this lack of feature? Can you confirm that access to the old version will not be closed until these features are restored?

[wrpeck]

Hey folks - I'm Wesley, the Amplify Studio Product Manager. Our rebuild of Data Manager fixed a lot of underlying issues, but it introduced some challenges for Markdown editing, which is why we didn't include this feature in our initial release.

That being said, I hear you: Markdown editing is a core part of your use cases for Data Manager. We are absolutely prioritizing bringing Markdown editing back to Data Manager, along with some additional improvements. We will not retire /content until Data Manager has Markdown functionality.

[Huetarded]

@wrpeck - Please keep in mind that this is not limited to just Markdown not working. If you scroll up this page, you will see examples of where data is not loading inside the Data Manager interface at all. As far as I can tell, this is for sites where the data was already created before the new Data Manager update was released. Which, for me, impacts a handful of sites that were already live before all this. In addition to that, the custom types do not work either. I mean, sure, you can write JSON-type structures in there, but is that really a solution for our clients (non-coding type)? I think not.

I'm still just at a loss as to why you would release something like this that did not have feature parity. It makes no sense.

Thank you for at least following up here, but I'm looking forward to seeing some updates soon because the last 2 months dealing with this issue has been the worst. And sadly it's reflecting on me in the eyes of my clients, not you guys!

[wrpeck]

@Huetarded - definitely. Custom Type support is part of our next Data Manager feature release as well, so your clients won't need to write JSON blocks.

I believe your issue above where data wasn't loading was resolved with a bugfix recently. Are you still encountering this issue? If you are, can you share your schema? I'll have a team member deep dive if the issue is still occurring.

[Huetarded]

@wrpeck - Yes, you are correct. I just double-checked a few sites that were suffering from the data not loading, and it does seem to be resolved now. Thanks for bringing that to my attention

Please keep us posted on the markup and custom types. Thanks!

[filipdanic]

Hi team, any updates on this? I see this has now been marked a feature-request, but to me it is still a bug/regression. Do we have any ETA?

[brianwthomas]

This isn't a 'feature-request' this is totally a bug. There's a reference to markdown support via announcements and in the documentation. However, the only way for someone to find it is to magically know it's under /content or to find this issue.

[kody435]

Any work around if possible please suggest.

Thank You

[brianwthomas]

@kody435 look above, there's a work-around by manually editing the URL in the amplify console.

[alessandrotr]

news about this?

I can't edit in markdown not even by replacing /data-manager with /content. It redirects me to the GraphQL Api editor.

stillmetime.-.main.-.Amplify.Studio.-.Google.Chrome.2023-09-25.17-28-37.mp4

[Huetarded]

@alessandrotr - This is happening because you are likely using unsupported directives, such as @function, @search, etc.. When you use these, it implements a redirect to the GraphQL editor, which impacts the /content path as well

That said, this issue is absolutely ridiculous and seems to be getting worse before any better. I would like to know why @murali-j-99 thinks this is a "feature request" and not a bug. The reality is that this feature already existed and we all build apps that depended on it. Then you guys pushed out an update that broke it, and now have failed for almost 8 months to make it right.

We are absolutely prioritizing bringing Markdown editing back to Data Manager

So what's going on here @wrpeck ? You made previous statements regarding this that are not being upheld at this point. You can't say you are prioritizing this, and then allow for it to be switched to a "feature request" and forgotten about.

[renebrandel]

news about this?

I can't edit in markdown not even by replacing /data-manager with /content. It redirects me to the GraphQL Api editor.

stillmetime.-.main.-.Amplify.Studio.-.Google.Chrome.2023-09-25.17-28-37.mp4

@alessandrotr did this work for you prior? We couldn't reproduce this on our end.

[renebrandel]

@Huetarded - Hi Jason - chiming in real quick to give you an update. First off, I’m sorry for your frustration and apologies that you’re experiencing this gap. I’m happy to also jump on a call with you to see if there’s some additional ways to enable your use case in a more convenient way while we’re still working on bringing the markdown editor to /data-manager. (Feel free to email me directly if you’re open to hopping on a call: renbran at amazon dot com)

The current /content workaround should still provide you access to the markdown editor - let me know if this workaround isn’t working for you. The /data-manager experience had some fundamental changes that addressed a range of other underlying improvements (faster data loading, 20+ bug fixes, support for non-DataStore APIs) but it doesn’t yet provide the markdown editor support. It is our intention though to introduce this into the /data-manager experience.

[Huetarded]

@renebrandel - You can replicate the issue if you use unsupported directives, such as @function, @search, etc.. in your schema. If you're not using them, it still redirects to /content as expected.

I don't even really know why we are calling them "unsupported directives" when they are clearly in the documentation but don't even get me started on that 🤬

[renebrandel]

@Huetarded - super sorry for the frustration it's causing. Our intent with the "unsupported directives" was to be explicit about which ones enable the full scope of functionality within Studio vs. only configurable via the CLI. The issue we want to guard against is that certain directives introduce side effects that might not be representable within a table view experience and can cause unintended side effects. I'm happy to look into this to see how we want to designate these feature asymmetries towards your expectations.

[alessandrotr]

news about this?
I can't edit in markdown not even by replacing /data-manager with /content. It redirects me to the GraphQL Api editor.
stillmetime.-.main.-.Amplify.Studio.-.Google.Chrome.2023-09-25.17-28-37.mp4

@alessandrotr did this work for you prior? We couldn't reproduce this on our end.

I created the project yesterday and it's my first time with aws.

I was looking for a way to edit fields in markdown and couldn't find it and I came across this thread after a google search.

@alessandrotr - This is happening because you are likely using unsupported directives, such as @function, @search, etc.. When you use these, it implements a redirect to the GraphQL editor, which impacts the /content path as well

I'm not sure how I can fix that, suggestions? =)

[Huetarded]

The current /content workaround should still provide you access to the markdown editor

@renebrandel - I was wrong above. I thought the use of unsupported directives was causing @alessandrotr not to be able to access the old content manager. However, I just started a brand new project with a few simple models and learned that /content no longer works under any circumstances. WTF?

You guys are killing me over here. Nobody is assigned to this ticket, and it's been open all year. To add insult to injury, it's still labeled as a "Feature Request" and not a bug. What's up with that @murali-j-99? What justification do you have for changing this from a bug to a feature request?

I'm sorry, but us asking for you to return a feature we were all using before you released code and broke it, and then released more code and broke the workaround, is not a feature request!

[ykethan]

Hey @Huetarded, could you provide us some additional information on the behaviour you are experiencing with the new application?
on opening the /content are you redirect to the GraphiQL page? this occurs if the GraphQL API may not have DataStore enabled.
on enabling DataStore you should be able to utilize the content manager.

To enable DataStore, under the Data modelling page -> GraphQL API settings -> enable conflict resolution.

[Huetarded]

Hi @ykethan - Yes, that's correct; I get the GraphiQL page.

It's good to know why it's happening, but it's also problematic. I'm not using DataStore, and in my previous experience with having it turned on, it caused issues with deleted records still being served by GraphQL. At the time, I remember some folks were filtering them out on the client side, but I don't think that's a very good way to handle it.

For the sake of conflict resolution and such, I understand why the records are just flagged as deleted as opposed to actually being deleted, but just like how DataStore does not return those records, GraphQL should not either IMHO

[ykethan]

Hey @Huetarded, thank you for the information and confirmation. Amplify Studio creates the GraphQL API without datastore enabled by default. With the new update we can now use the new Data manager to interact with the GraphQL API without the conflict enabled.
I believe a improvement can be made here to provide a message that conflict resolution has not been enabled for the content manager. I will pass the feedback to the team.