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 inherited a legacy website written in old zul and have to add new datebox component for birthday datepicker.
Have added a constraint to accept dates before a given date but that triggers an error alertbox from start as the date presented/selected by default on the datepicker is today.
I wouldn't want to use a workaround but to all due respect it seems like this is something over the top feature I'm looking for in zk's reality:
The main showcase for zul does include a birthday datebox, but pretty lame as it doesn't contain any constrain on age.
There is zk fiddler to show how the before constrain works, but that just proves my point that it doesn't select the first proper date for default date at least, if there is no clean way of setting it.
There is forum post that proposes a workaround to set the default year, so Zk is most probably incapable of doing this without a workaround.
There is an open ZK Jira issue from 2017 that addresses somewhat this issue, with a proposed solution pretty much the same as the workaround mentioned in the above point - so the hope is kinda lost, have to go on the workaround route.
I did try that workaround (after the forum post, as that has default year), but the workaround doesn't work for me. It does execute the
this.setValue(initialDate);
And I see that the value is set into the datebox's _pop/_value and _pop/_end nodes but no difference is visible on the datepicker box, still today is preselected altough it is greyed out - so no effect.
Still, when I try it in a fiddle with version 6.5.8.1, the oldest engine that exists, it does work, but not locally with v5.0.11.
In the buglist for this version there is no mention of datebox. Tried to look into to some bugs that might be interfering but turns out it was just another episode of me wasting time with this.
Tried in the 5.0.11 sandbox and it doesnt work with that version. The structure of how I use it is imitated in the linked fiddler. Hints on a workaround that works on this version?
ZK 5.0.11 is a bit on the older side currently, so it might not accept exactly the same overrides as later versions. If I understand the issue correctly, it boils down to either
1 - setting a value before Datebox is rendered to have a "initial date" opened in calendar.
I'd say that's the easy way out, since you can use either composing or databinding to set the value of the datebox during page rendering. Here's a small sample using databinding and zscripts, but the same logic should apply from composer with setValue(). You mentioned that this doesn't work for you locally with 5.0.11 though. Can you share the code that you are using for this? Sample code here in fiddle I can run it on local 5.0.11, and it set the date before popup is opened.
or
2 - setting an initial date (which doesn't affect the selected value) but would be the target for the opened calendar.
This is not a default ZK 5 behavior for datebox. If you want that effect, you would need to customize it using an override script. Simplest way in can think of in ZK 5 is to use the open event of the datebox popup here's an example of what it would look like (package in a script tag in a single page for the example, would use a global js file for real deployement) example here
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.
We have migrated code from Yocto1.5 to 1.7 and it seems with using the same configuration file(local.conf), I found that a lot of libraries previously installed on the 1.5 image(fsl-image-gui) was not present in the 1.7 image(core-image-sato)
I have manually added most of the packages except for two
libbeecrypt_cxx.so
liblcms.so(cmsutil)
I have already put in the code below and libbreecrypt was insalled but not libbeecrypt_cxx
IMAGE_INSTALL_append += beecrypt
I have not found a recipe/package for cmsutil. Anyone information regarding these would be appreciated.
Best Regards
Yuri
Well, regarding the beecrypt part of your question. Shortly after the 1.5 release, building the c++ bindings were made optional, and defaults to off.
See patch making c++ optional
Thus, what you need is to add a beecrypt_4.2.1.bbappend file in your own layer which includes
PACKAGECONFIG += "cplusplus"
That the best, longterm solution. You could also set
PACKAGECONFIG_pn-beecrypt_append = "cplusplus"
in your conf/local.conf.
I have implemented a converter to convert Int32 to String to be able to binding a property to a textBox.
I implement this converter in the namespace MyApp.Converters and it is called Int32ToStringConverter.
Then, in my axml I add the reference to my converter as follow:
<Window x:Class="MusicaDB.Views.PrincipalView"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:i="namespace:System.Windows.Interactivity;assembly=System.Windows.Interactivity"
**xmlns:converter="clr-namesapce:MyApp.Converters, aseembly=MyApp**">
Later, in windows.Resources I have:
<Window.Resources>
<**converter:Int32ToStringConverter** x:Key="Int32ToStringConverter" />
</Window.Resources>
I get the error that the tag Int32ToString converter does not exist in the namespace MyApp.Converters,assembly=MyApp.
I have the project in the local hard drive, in the project properties, the destination .NET is framework 4.0, not framework 4.0 client profile and I try to clear the solution and recompile but the problem persists.
Mainly, this is the two solutions that I always find, but don't resolve my problem.
Three fixes to make here:
No spaces -> xmlns:converter="clr-namesapce:MyApp.Converters,aseembly=MyApp"
No misspellings -> xmlns:converter="clr-namespace:MyApp.Converters,assembly=MyApp"
Right delimiters -> xmlns:converter="clr-namespace:MyApp.Converters;assembly=MyApp"
From the the documentation:
Note that the character separating the clr-namespace token from its value is a colon (:) whereas the character separating the assembly token from its value is an equals sign (=). The character to use between these two tokens is a semicolon. Also, do not include any whitespace anywhere in the declaration.
Another possible solution to this problem is that you're not using the same version of .Net in your project and your library.
I am exploring as to why this is happening, but if your converter is in the main assembly, removing the assembly= from your xmlns:converters tag should remove that build error.
For the record ...
I've face a similar problem and if I removed the ";assembly=X" part from the XAML it worked fine
But don't really understand the reason.
As suggested in this blog:
http://zoomicon.wordpress.com/2012/07/02/fix-the-tag-xxx-does-not-exist-in-xml-namespace-clr-namespaceyyy/#comment-7761
I see two possible causes. The first is that you misspelled "assembly" as "aseembly" in the first starred line. Changing the spelling might be enough. The second possibility is that you haven't added MyApp.dll to your project references, which appear like this
in Visual Studio.
All answers are right. And after trying all of them and you cannot configure why its happening, everything seems alright, Please restart the Visual studio.
That worked for me after wasting almost 1 hour. I found everything ok, but restarted the VS with administration.
use the assemble tag only if it is in another project.
other wise use just namespace tag alone.
For me this fixed the issue
In my situation, I had the same problem with xmlns:local="clr-namespace:<mydefaultnamespace>".
I solved this changing the order of the includes. I put it first and all was solved.
A strange behaviour, but this was my workaround that I found in my situation.
In my case, the assembly which contained the namespace was not physically there.
I checked the references of the assembly that had the build error and looked at the properties of the referenced assembly in question.
I navigated to the path and discovered the assembly was indeed missing (which I realised was my own doing), giving rise to the misleading error.
There is one very obscure case when you get this error - if you're using Microsoft.mshtml.dll and you upgrade to Windows 10 anniversary edition, or as it turns out the Creator edition too.
Even if this isn't what happens to you make sure the library containing the component that cannot be found can be fully compiled. Look in the error list (not the grid but the Output console) for any clues.
In my case I was using Microsoft.mshtml.dll as part of an HTML editor and it was unregistered somehow (in the GAC).
The following article explains with screenshots:
https://techninotes.blogspot.com/2016/08/fixing-cannot-find-wrapper-assembly-for.html#comment-form
In short I had to run a Visual Studio command prompt (as admin) run these commands:
cd C:\Windows\assembly\GAC\Microsoft.mshtml\7.0.3300.0__b03f5f7f11d50a3a
regasm Microsoft.mshtml.dll
I did say obscure :-) The important point is to read the errors that may be buried amongst all your warnings because there might be an important clue.
This can be especially confusing if an Operating system update suddenly breaks your project.
I was temporarily replacing a NuGet dll with a local one when this happened. Turned out the assembly was not the same version as the one I was replacing. I built my assembly with the correct version and it worked.