Image prop is an empty string

[eNzyOfficial]

Describe the issue
For me, the image prop is always an empty string, I tried to uninstall and reinstall the extension but I have the same result. Not sure if something changed recently with LinkedIn that could have caused this?

Additional context
I also dropped you an email, not sure if you've had time to take a look. Thanks!

EDIT:

Also, if the users work experience is set to current, is there a way to add this as an extra property? With the end date being an empty string, it's hard to tell if the person is still working there or just forgot to put an end date.

EDIT2:
It might be a good idea to add .replace(/\s+/g, " ") to the first and last name, I noticed that some of the profiles have a double space in their name, for example:

https://www.linkedin.com/in/claudiasirinda/

EDIT3:

For education, in the json, description is missing

[eNzyOfficial]

_outputJsonLegacy.basics.picture = await this.getDisplayPhoto()
_outputJsonStable.basics.image = await this.getDisplayPhoto()

It looks like the getDisplayPhoto isn't being called, I managed to get it working using the above at the end of tryParse, I'd make a PR for it but I'm not sure if it's better being called somewhere else.

[joshuatz]

Display Photo

As far as I can recall, this extension has never supported the profile.basics.picture or .image field for a profile picture. The getDisplayPhoto method was added in #21, exclusively for use with the vCard export feature, and the reasoning is partially explained in the docs and code comments, but for clarity:

• LinkedIn does not make it easy to hotlink to profile pictures. The URL returned by getDisplayPhoto is actually a short-lived semi-private URL. I believe LI is doing this to discourage scrapers and as a modest privacy feature.
• I can get around this limitation (short-lived private URL) for the vCards export feature, by converting the actual bytes of the image into a base64 string and stuffing it into the vCard file. Once it is stored as base64 string, it doesn't matter if LI deletes the image that the original URL was pointing to, or even if the user does - the binary information is stored directly with the export.
• I don't believe the above workaround should be applied to the JSON Resume export; I think most users would get annoyed with their JSON export suddenly containing thousands of extra characters (base64 string), some platforms that accept JSON Resume are probably not expecting base64 data URIs, and even if the previous things were not true, all this would be for an image that would be tiny and low quality.

I don't think there is going to be a suitable workaround here, so my vote would be for continuing to omit the image field. If users really want to include their picture as part of their JSON Resume, they should host the image themselves (Imgur is a quick and free option, but there are hundreds of options out there) and manually fill in that field.

Work End Dates

I appreciate the suggestion and get where this is coming from in terms of visually inspecting the JSON, but I'm still not convinced it is necessary. The convention is already that if the field is empty or missing, that means the work entry is ongoing (to present day), and a quick test with some online JSON Resume based tools confirms this, such as ResumeFodder.

Profile Name Normalizing

I would be OK with implementing this, but am generally opposed. I realize I'm starting to sound like a bit of a stubborn stick-in-the-mud, but here is my reasoning: I think most people using this tool are using it to improve their prospects of getting hired - either right now, or in the future. Even if you provide a very polished resume, most employers look up applicants on LinkedIn anyways and scan their profile. I don't like the idea of my extension "masking" a possible issue with your LinkedIn profile - if a user didn't intend for there to be two spaces between parts of their name, they should correct it in their profile, so it is correct in both places that employers will look, instead of just their resume.