I created Candy Machine and I noticed that some NFT images are not displayed neither on wallet or solscan. Metadata and images were uploaded and pinned on Pinata using Candy Machine upload command which finished successfully.
Here is an example of broken NFT.The metadata URI is pointed to: and image is pointing to. I looked at metadata several times and could not find what is the issue and why is this happening to some of the NFTs (here is the example of valid NFT that does not have this problem).
Questions:
What is the problem with metadata which is causing image not to be displayed?
What is the best way to fix this? Metadata are mutable and I am planing to use metaboss to update URI of metadata file. Is this correct way of fixing this problem?
If you look at the URI metadata on solscan here
https://solscan.io/token/4ToXb3aD5YLpXqyZhcdp5ynpbXXFFjKjsaw1x94CTd7A#metadata
and swap to the URI version of the metadata for some reason it's returning an object keypair value out of every single character in the JSON for some reason, extremely weird. I'd highly recommended reuploading this JSON metadata file and then updating the metadata URI in the NFT to make the changes.
Metaboss is a great tool as you have researched that can do this for you.
Upload new Metadata json to ipfs or arweave.
Use Metaboss to udpate the NFT's metadata URI.
Hopefully this fixes your issue.
While not a conclusive answer as to "why" this happened, I don't really know the why. This is my first time in all the NFT's that I've seen that have behaved this way upon an upload and displaying the metadata.
If that doesn't fix your issue please stop by the Metaplex Discord server and chat with us there. :)
Edit: After further inspection it turns out your JSON file is of an invalid structure for this particular NFT so will definately need replacing.
Tony Boyle has a great point with updating your json.
Your problem gets visible when you run the json through a JSON validator.
It will show that you have too many } in there. Therefore parsing the JSON fails in solscan, phantom etc.
What you have to do is
Modify the metadata to be a valid JSON file
upload it again
update the NFT uri e.g. with metaboss (if you need to update multiple NFTs) or if its just one / a few https://sol-tools.tonyboyle.io/update-nft
Related
I have been going through the Sugar CLI for the first time and was hoping to clarify a couple of things to make sure I am creating the Candy Machine correctly. It's clear from the documentation (https://docs.metaplex.com/developer-tools/sugar/configuration) that the creators wallet should now be added to the Candy Machine config file.
But where should sellerFeeBasisPoints and collection properies go? Does it hurt anything if they are present on both the config file and each metadata file?
For the collection property - is this taken care of with the new collection.json and collection.png? Does this need to be present at all on either the config or the metadata file?
Appreciate any clarifications!
sellerFeeBasisPoints goes into the configuration file, like creators.
It doesnt hurt anyone if they are present on both metadata and config, but the one inside the metadata wont matter at all because its deprecated, the important is the one inside the config file.
collections is managed with collection.json and collection.png, you dont need to set anything extra on metadata or config file, you just need the collection metadata and collection image, so sugar will deploy this metadata into the selected storage, then will create and mint ur collection NFT and finally will attach that collection NFT publicKey to all NFTs that will be minted from the created candy machine. If you dont provide the collection.json and collection.png, then you will have to create and mint the collection NFT by yourself and then manually add that collection to each minted NFT that doesnt have a collection attached.
I want to move files my email to attachment to Azure BLOB using Power Automate. I am aware of the BLOB storage connection but I can't use it as I don't have the access key.
After surfing Google, I managed to find the below link. I need help on how to get the x-ms header and how to choose the folder inside the BLOB to upload the file into.
I lack all kind on experience in HTTP and Azure BLOB. :(
Please help.
Link: https://powerusers.microsoft.com/t5/Using-Flows/how-to-upload-to-blob-container-via-sas-url/m-p/125756#M3360
After reproducing from our end, Here is how we could able to save files in our blob from the HTTP connector.
We have used “x-ms-blob-type” as a header with a value of “BlockBlob”. Make sure you add the path to your storage account in URI in the below format.
https://<STORAGE ACCOUNT NAME>.blob.core.windows.net/<CONTAINER NAME>/<FILE NAME><SAS>
RESULT:
I'm trying to get emoji's from a another server.
I creates a server object for the server, it is a constant because I want to only pull from this server.
for emoji in main_tuple:
emoji_name_id =await server.fetch_emoji(emoji)
emoji_array.append(f"<{emoji_name_id.name.lower()}:{emoji_name_id.id}>")
error:
nextcord.ext.commands.errors.CommandInvokeError: Command raised an
exception: NotFound: 404 Not Found (error code: 10014): Unknown Emoji
I should mention I want to display it another server, I know this is probably obvious but yeah.
main_tuple is a directionary in a database that has the emoji id and name.
the error
Also the bot is part of the server it's getting the id from.
I have looked at: discord.py emoji all servers bot in
and it does not work for me.
First Issue, you are making a wrong reference.
<:Name:ID> and not <Name:ID> (if you don't see it, you missed the first colon)
Another issue,
emoji_name_id.name.lower()
Custom emojis are to have to have 'exact' name and ID as they have, by using lower method, you would be trying to reference a wrong custom emote.
For example:
The actual emote which might have the following reference <:ThisIsACoolEmote:ID>, while you are appending <:thisisacoolemote:ID> which doesn't exist
To mitigate this, you can just append str(emoji_name_id) which will automatically give you the correct emote reference which is in the format <:Name:ID:> and yes, it also will format animated emojis too, i.e:<a:Name:ID>
also fetching here might not be the best practice, you can use bot.get_emoji instead which gets emote from internal cache if you have access to member Privileged Intent.
The Google Drive API v2 to v3 migration guide says:
The exportLinks field has been removed from files. To export Google Documents, use the files.export method instead.
I don't want to export (download) the file right away. "files.export" will actually download the file. I want a link to download the file, later. This was possible in v2 by means of the exportLinks.
How can I in v3 accomplish the same? If it is not possible, why was this useful feature removed?
Besides, (similar problem to above) downloadUrl was also removed, and the suggested alternative ("files.get with ?alt=media") downloads the file instead of providing a download link. This means there is no way in v3 to get a public short lived URL for a file?
EDIT:
there is no way in v3 to get a public short lived URL for a file?
For regular files, apparently yes.
This seems to work fine (a public short lived link to the file with its right name and contents):
https://www.googleapis.com/drive/v3/files/ID?alt=media&access_token=TOKEN
For google apps files, no (not even private, as v2 exportLinks used to be).
https://www.googleapis.com/drive/v3/files/ID/exportmimeType=TYPEv&access_token=TOKEN
Similar to regular files, this URL is a short lived link to the file contents, but lacking of its right name.
BTW, I see the API is not behaving consistently: /drive/v3/files/FILEID delivers the right file name, but /drive/v3/files/FILEID/export does not.
I think the API itself should be setting the right Content-Disposition, as it is apparently doing when issuing a /drive/v3/files/FILEID call.
This file naming problem invalidates the workaround to the lack of ExportLinks in v3.
The v2 ExportLinks allowed me to link a file (which is not the same as getting its content right away). Anyone logged in and with the proper permissions was able to access it, and the link didn't needed any access_token, and it wasn't short lived. It was good and useful.
Building a link with a raw API call like /drive/v3/files/FILEID/export (with mandatory access_token) would be an close enough workaround (it is temporary and public, not the same as it was, anyway). However, the naming problem invalidates it.
In v2, regular files have a WebContentLink and google apps files have exportLinks. In v3 exportLinks are gone, and I don't see any suitable alternative to them.
Once you query for your file by id you can use the function getWebContentLink() to get the download link of the file (eg. $file->getWebContentLink() ).
I think you're placing too much emphasis on the word "method".
There is still a link to export a file, it's https://www.googleapis.com/drive/v3/files/fileIdxxxxx/export&mimeType=xxxxx/xxxxx. Make sure you URL encode the mime type.
Eg
https://www.googleapis.com/drive/v3/files/1fGBQ81haNU_nEiC5GITZD3bxT0ppL2LHg-C0ubD4Q_s/export?mimeType=text/csv&access_token=ya29.Gmo0BMvO-pVEPKsiD9j4D-NZVGE91MChRvwOcBSg3cTHt5uAClf-jFxcovQScbO2QQhwHS95eSGW1eQQcK5G1UQ6oI4BFEJJkntEBkgriZ14GbHuvpDL7LT2pKA--WiPuNoDDIuZMm5lWtlr
These links form part of the API, so the expectation is that you've written a client that sends authenticated requests, and deals with the response data. This explains why, if you simply paste the link into a browser without an access_token, it will fail. It also explains why the filename is export, ie. it isn't intended that your client would ever use a filename, but rather it should receive the data as a stream. This SO answer discusses the situation in more detail How to set name of file downloaded from browser?
We are collaborators on a Parse.com App and we need to recreate the App in another account as we are ending our relationship with the original App creators.
We have copied all the classes and exported all the data from the previous App but are getting errors with the JavaSript API (Access Denied/403 issue). Has anyone else experienced this? What did you do to overcome the problem?
Thanks!
The Parse.com dashboard has export to JSON which you can then import from the data browser on your second app.
Object IDs will not be preserved.
One big thing to be aware of:
Any referenced PFFiles are NOT exported, so all the references in your rows are not valid, as the new database is not part of the ACL of the old PFFiles.
Either export+import the PFFiles manually, or change the ACLs, if that is indeed possible.