Deciding what fields are included in posts result about wordpress_client HOT 12 CLOSED

It sounds perfect and I'm impressed of your support. Please push it so that I could test it.

from wordpress_client.

Hey @rafaellop,
I have pushed the changes on to a new branch feature/_fields-support
Could you test it out and let me know?

from wordpress_client.

Thank you @ArunPrakashG . I've tested the branch and it works as you described giving me access to raw data which I can manipulate now. 👍

By the way, do you maybe know is there any way to get the fields in raw (non rendered) format? For example the excerpt is returned as html but the html is generated by Wordpress and not the excerpt I typed when creating post. I know I can use the context: RequestContext.edit, parameter to get raw, but this requires authorization and for performance and security purposes I'd prefer not to overcomplicate.

from wordpress_client.

Yes, it works perfect. Please push into main if possible.

Regarding my question, I retrieve posts with your package and in the response I get posts fields I ask like title, excerpt, link, etc. The WordpressResponse contains data which contains the posts data in a list. Some of the fields are returned as basic html (for example the link field), but some are rendered to HTML by Wordpress and available as a value of the rendered field. However I don't think if there's an easy way to get these rendered fields as raw. I mean without using the RequestContext.edit context for the ListPostRequest which requires authentication as a user with rights to edit posts on the Wordpress side. As far as I googled it's possible to modify the API behaviour at the Wordpress backend or create a custom field. I'll probably stick with a straightforward stripHtmlIfNeeded() from intl.

Please don't bother with that. It seems I have found the answer and described it here above for some people who may be struggling with the same thing in the future. Thanks again!

from wordpress_client.

@rafaellop latest version has been pushed to pub.dev.

Version: v8.3.7

from wordpress_client.

Outstanding! Thanks a lot!

from wordpress_client.

Hey @MiniSuperDev ,
As previously mentioned on the same thread, i don't intend on making every field nullable because that is a very bad approach in a type-safe language. Sure, you could have certain fields as nullable, but some fields should always be non nullable. i believe the fields that could be marked as nullable are already like so. If you think i may have missed out a few, please share those.

Also, a better solution is to define a model class on your codebase for such cases with your required fields, then use the raw requests for the purpose and parse to the defined model class.
this provides more flexibility in case you want to integrate a local database, etc, in the future.

Also, it would be better if you could open a new issue and link this to it as this issue has already closed for some months now.

from wordpress_client.

I've found there's a way to do that using the extra parameter of the ListPostRequest() but unfortunately exception occurs because you made an assumption that some fields will be always available in the response from the API in the Post.fromJson(Map<String, dynamic> json) factory. So, despite the extra does the job and the api returns only the fields I need, there's exception in this function. For example a call:

      ListPostRequest(          
        perPage: 60,        
        order: Order.asc,
        extra: {'_fields' : 'author,id,excerpt,title,link'}
      ),

throws exception in the line 55 with hardcoded convertsion guid: Content.fromJson(json['guid']), in the https://github.com/ArunPrakashG/wordpress_client/blob/master/lib/src/responses/post_response.dart#L55

The same happens for other fields that are not specified in the extra but hardcoded in this function.

Providing fallback values for the Content.fromJson() and for castOrElse() fixes the exceptions and it seems the return value is provided properly. However some fields of the Post class are marked as required and I'm not sure if providing fallback values like empty strings, empty maps or just zero ints won't cause any issues.

You can test the issue by calling a minimal fields list like this:

ListPostRequest(          
        perPage: 60,        
        order: Order.asc,
        extra: {'_fields' : 'title'}
      ),

and the list() function will throw exceptions.

from wordpress_client.

Hi @rafaellop
I have not considered the functionality wordpress provides via the _fields query parameter in the library during development. The complication is because dart is a type safe language and since we have a model class with all the properties, it is going to throw errors if some fields are missing. There are work arounds for this like we could mark the fields as nullable, however, i dont think marking every property nullable is a good approach.

Yes, as you observed, we could use the extra parameter on the request class, or even pass custom query parameters via the queryParameters property to the request. but the issue originates during deserialization of the JSON response.

I have checked through the source code and i think, one of the easiest methods is to not handle the deserialization process from the library, instead, delegate it to the library user's codebase.

My assumed workflow would be:

• Add a new method to each Operation. i.e., in terms of a ListOperation Mixin, Add a new method called listRaw.
• It will take in the ListPostRequest request class as parameter.
• Returns an instance of WordpressRawResponse which is the internal response instance, This instance can be then mapped to the required model class, the following data is present in this instance:

final dynamic data;
final int code;
final Map<String, dynamic> headers;
final Map<String, dynamic> requestHeaders;
final Map<String, dynamic> extra;
final Duration duration;
final String? message;

Additionally, this instance has properties for various error type and a map method called asResponse<T> which takes in a decoder method. This can be used to map this instance to a model class.

On your end, to utilize this, instead of calling the list method, you will have to call listRaw method, with the same parameter. the return type will be WordpressRawResponse. You will have to define a custom model class with the required fields, then pass it to the decoder property in the asResponse<T> method or manually handle it via the map<T> method.

Note that the content in the WordpressRawResponse is of type dynamic, and not a map. therefore, there is a chance the content can be null.

Let me know if this works out for you, i will try to push these changes on another branch for you to test.

from wordpress_client.

I'm glad to know it works.

On the other case, can you provide examples? i have not worked on wordpress for quite some time now.

from wordpress_client.

i believe there is already a deprecated method in the helpers class for html stripping. I am not entirely sure, tho.

Either way, I'm glad your issue is resolved (both of them)
i will merge it to the main branch and plan a release, possibly tomorrow.

from wordpress_client.

@ArunPrakashG Hi,
I have a similar case, why didn't you let all properties be null?
Since _fields is usually used a lot to make the response lighter.

from wordpress_client.