Thanks, this fix is included in beta2!
Great, thanks for that! This one's included in beta2.
Done, development moved to https://www.drupal.org/project/ai_seo →
Yup, will create a version for that module and move the development there.
Thanks for that, I've pushed out a new version beta3 that fixes this bug and also changes the model in use to gpt-4o for cheaper and faster response generation.
The patch didn't work for us. Also facing the same issue where the open / closed views filter doesn't work unless caches are cleared, and after that you will only see the correct results once. Disabling the caching in the view itself doesn't help either.
Please check the earlier comments. This has been fixed already in the active branch.
I've pushed out a new release to dev that should fix this. So now we specify in the prompt that we want the results in markdown (which the API would provide anyway) and we then use thephpleague/commonmark library to convert that markdown into HTML.
And it works pretty darn well! This way also does save on some tokens so it's a win win solution. Thanks!
Latest update to dev-branch fixes this and there's now a new service that renders a given entity's view mode in HTML. Thanks!
I also generalised the service a bit so that it can now take:
- Entity type ID
- Entity ID
- Revision ID
- View mode
- Langcode
I think with those options this module could be extended to do a lot of things.
I faced that issue previously but hadn't had it happen for a long time so I thought the prompt updates had fixed it.
Might be better that we do change the module to do just that. Ask for markdown and then convert it to HTML in the back end using a composer plugin like the one drupal/markdown is using: https://github.com/thephpleague/commonmark
It might save a few tokens as well I imagine.
So let's re-open this one for now, thanks!
Thanks @NicholasS, good idea that appending the request for HTML to the prompt. I patched in the code from your MR and changed the place where that request is appended to analyzeUrl-function instead, that way it'll always be appended no matter how the service is used.
Good catch, thanks!
Thinking about this more, should there be a $options=[] parameter in that function instead of us adding this $seed and whatever else is added at a later date to the API?
That solution 2 actually worked. Great suggestion, thanks!
It's a pretty convoluted way of putting the HTML render together. I'll probably make a separate service to handle this to keep things a bit cleaner.
Will include this in a future release so I'll re-open this for now.
Good catch - fixed in 2.1.0, thanks!
Fixed in 2.1.0, thanks!
Fixed in 2.1.0, thanks!
Fixed in 2.1.0. Thanks everyone!
Fixed all but the function renaming, thanks!
j-vee → created an issue.
The issue with renderPlain ends up being is that it doesn't produce the same full HTML page as a HTTP request does and it therefore isn't the right tool here. What I did with the latest release though was that I changed file_get_contents function to use Drupal's HTTP Client service instead.
The patch here broke functionality with clicking on the fieldset to add a new paragraph instead of the Add-button directly. The same issue raised by #10.
Issue was javascript using currentTarget instead of target to select the button inside the fieldset element. Attached patch fixes that issue.
MR!6 works great, thanks.
Works great, thanks for the patch!
+1 works! Thanks
Works fine. Can we get a new D10 release please?
Hi there, thanks for the reports. There's now 2.0.3 available to fix this: https://www.drupal.org/project/ckeditor_accordion/releases/2.0.3 →
Let me know if the issue persists for you still!
Tests are failing but the functionality itself is fixed using this patch. Thanks!
I needed a patch for this one so I opened up a MR. This one fixed the issue for us.