I'm having this weirdest issue with adding hero banners to my Shopify store today. I've been making this particular set of changes multiple times over the past 6 weeks or so without any issues whatsoever. What I've been scouring the internet for is a list of "illegal" characters so I can be sure I'm not going to have this same issue going forward. Anyone know where to find that?
Ex. this is what it normally looks like in my Theme Kit upload:
20:41:10 [development] processing assets/2021-05-24_Generic_Desktop-Slider-(1450x500).jpg
20:41:12 [development] Updated assets/2021-05-24_Generic_Desktop-Slider-(1450x500).jpg
What I got instead was this:
20:41:07 [development] processing assets/2021-05-19_Subscribe+Save_Desktop-Slider-V1-(1450x500).jpg
[development] (assets/2021-05-19_Subscribe+Save_Desktop-Slider-V1-(1450x500).jpg) "assets/2021-05-19_Subscribe+Save_Desktop-Slider-V1-(1450x500).jpg" contains illegal characters
Anyone else have this problem? Thoughts, comments, suggestions? Know a place where I can find a list of illegal characters?
Since this is the only time that I've had a file name with a + in it, and as I'm writing this, I'm changing it to a - which seems to have done the trick... this time!
Related
I've run into an challenge/posible incompatibility between gatsby-source-graphcms and gatsby-plugin-react-i18next, for which there appears to be virtually no information online and I'm wondering if anyone else has encountered this before please.
I'm working on adding localisation to a site which uses gatsby-source-graphcms and the Gatsby File System Route API to build pages dynamically. Everything was going fine, until I tried to use the $language GraphQL query variable made available by gatsby-plugin-react-i18next with the locale filter field in GraphCMS, which yielded this error message:
Variable "$language" of type "String!" used in position expecting type "GraphCMS_Locale"
The one and only reference I've been able to find to a similar issue was on GraphCMS' public Slack, where someone referred to abandoning gatsby-source-graphcms I favour of gatsby-source-graphql due to this. However I'm hesitant to do this, as that would basically means re-writing the entire site for me! 😢
I've been trying to find some way to feed the page query a second variable, which duplicates the value $language variable from gatsby-plugin-react-i18next but is declared as the correct data type for GraphCMS, or perhaps to somehow cast the string to GraphCMS_locale but have had no luck so far.
Has anyone found a way to make gatsby-source-graphcms play nicely with gatsby-plugin-react-i18next please?
The WIP code for this can be seen here: https://github.com/binghamchris/paddelbuch/blob/feature-i18n/src/pages/index.js
Apologies if the code is a bit bad somewhere. I'm not a web dev (this is a community project I'm volunteering on, where there's no professional web devs) and am really just hacking away on copy-and-paste code 😉
Thanks in advance for any help anyone can offer
I found a super hacky workaround, inspired by #notrab's kind help, in case it helps anyone else:
I added the following to gatsby-node.js:
exports.createSchemaCustomization = ({
actions: { createTypes, printTypeDefinitions }
}) => {
createTypes(`
type Locale implements Node {
language: GraphCMS_Locale
}
`);
};
This changes the GraphQL data type on the language field in the i18next translation data to GraphCMS_Locale, which then means both data types needed by both gatsby-plugin-react-i18next and gatsby-source-graphcms match... and so far it seems to be working in dev mode!
I am using react-native-calendar-picker from github to use a calendar in my app. The problem it's that everytime I run it, I get some warnings like:
As seen there, there's something about node_modules\react-native-calendar-picker\CalendarPicker\DaysGridView.js , and there are 4 warning, with rows 254,255,256 and 248. Going to that file, I found that those lines are:
So, the problems seems to be somewhere at selectedRangeStartStyle, selectedDayStyle and selectetRangeStyle which I have setted in my componenet with #XXXXXX, as hex color codes. Any help would be appreciated, thanks!
I am also getting the same warning because of those lines. It was a change introduced by this commit https://github.com/stephy/CalendarPicker/commit/081a07f6c95fc178d17295ef0cd3f68f2b7d117f to fix this issue https://github.com/stephy/CalendarPicker/issues/246
Reverting the changes locally on the file stopped the error from popping up in my console, but that is just a quick workaround i found for now only.
I just updated my version of hugo to 0.53 (from a rather old 0.21) and one of the consequences of the update is that string
<!--more-->
that was previously used for identifying the end of the blog post summary is now replaced with the string HUGOMORE42. Also, the summary end is not correctly triggered.
Can anyone point me in a direction to fix this? If I downgrade to an earlier version of HUGO then the problem disappears, so I'm guessing it is an identifier that was changed along the way.
I tried with my old version of the default hugo-lithium-theme and with another theme. It might be a problem with the theme, but if that is the case where can I fix that? (I have various local modifications of the theme in layouts that might be the culprits).
Googling HUGOMORE42 yield quite a number of webpages that appear to have the same problem so that is not that useful.
For the past month or so I have been trying to solve this problem. I checked the website extensively, including all tutorials I could find, and even bought a book. I previously posted but have had no luck. Hopefully I have more info to get some help.
Basically I have a map in my FileMaker database. Everything works fine, except for one thing I would like to change. When I roll over each marker I would like to see the label show the customers name, instead of the static "Marker 1", "Marker 2", etc.
I included a link to dropbox that has the html, the MarkersArray custom function and hopefully all the info that's passed to the Html that may be needed. Through much trial and terror, I can't figure out how to make it happen. Any help or guidance would be greatly appreciated.
Thanks
Steve
https://dl.dropboxusercontent.com/u/71328624/GoogleMapsDocs/html.txt
https://dl.dropboxusercontent.com/u/71328624/GoogleMapsDocs/ss1geo.png
instantiate a variable that calculates the company name inside of your for loop. replace "Marker" +i with the variable.
I am using the Drupal 7 Migrate module to create a series of nodes from JPG and EPS files. I can get them to import just fine. But I notice that when I am done importing them if I look at the nodes it creates, none of the attached filefield and thumbnail files contain filename information.
Upon inspecting the file_managed table I see that both the filename and filemime fields are empty for ONLY the files that I attached via the migrate module. This also creates an issue with downloading the files.
Now I think the problem has to do with the fact that I am using "file_link" instead of "file_copy" as the file operation I specify. The problem is I am importing around 2TB (thats Terabytes) of image files. We had to put in a special request with Rackspace just to get access to that much disk space on our server. So I can't go around copying from one directory to the next because of space issues. So "file_link" seems like the obvious choice.
Now you probably want to see how I am doing this exactly, so here is the code snippet:
$jpg_arguments = MigrateFileFieldHandler::arguments(NULL,
'file_link', FILE_EXISTS_RENAME, 'en', array('source_field' => 'jpg_name'),
array('source_field' => 'jpg_filename'), array('source_field' => 'jpg_filename'));
$this->addFieldMapping('field_image', 'jpg_uri')
->arguments($jpg_arguments);
As you can see I am specifying no base path (just like the beer.inc example file does). I have set file_link, the language, and the source fields for the description, title, and alt.
It is able to generate thumbnails from the JPGs. But still missing those columns of data in the db table. I traced through the functions the best I could but I don't see what is causing this. I tried running the uri in the table through the functions that generate the filename and the filemime and they output just fine. It is like something is removing just those segments of data.
Does anyone have any idea what this could be? I am using the Drupal 7 Migrate module version 2.2. It is running on Drupal 7.8.
Thanks,
Patrick
Ok, so I have found the answer to yet another question of mine. This is actually an issue with the migrate module itself. The issue is documented here. I will be repealing this bounty (as soon as I figure out how).