I am using PHPCS for the first time with standard=WordPress. While sniffing a class file I get the following error:
Method name "Media_Content_Taxonomy::mctf_register_media_content_taxonomy" is not in camel caps format.
I Googled but could not find an exact work around for this.
I tried by changing the method name to (may be wild guesses!)
Mctf_Register_Media_Content_Taxonomy
and
MctfRegisterMediaContentTaxonomy
but could not get rid of the error. I don't know how to fix this.
The WordPress Coding Standards use a naming convention of class names with underscores, so you appear to be running PHP_CodeSniffer without using the WordPress standard.
Try running phpcs -i to check it (and the sub-standards) is installed.
Related
I'm using BTDF and the settingfilegenerator to dynamically configure the bindings. My first binding was a SQL binding and it worked fine. However, most of my binding settings are UNC paths and I'm getting errors when trying to apply the settings. I have tried about every combination of quotes and doubling the backslashes to try to handle this but nothing is working. Surprisingly I haven't been able to find anyone else with the same issue. Any ideas?
parsing "\Myserver\Myshare\Folder\SubFolder\inbound\Enroll\%SourceFileName%.834" - Unrecognized escape sequence \i.
Thanks for the comments. It made me look into where it was actually failing instead of the error message. It appears to be an issue with the the install-biztalkapplication.ps1 script. I'm not sure the origin and if there were any changes made to this script. I commented out this block (full block not shown) and this last line is what is causing the error. There seem to be several versions of this file available. I'll do some additional research and provide an update.
get-content -path "$btdfdeploysettingsfile" | foreach-object {
$line = $_
$hashconfig.getenumerator() | foreach-object {
Thanks for everyone's help to point me in the right direction. In the end the issue was in the install-biztalkapplication.ps1 and not with BTDF directly. I removed the bad lines and the replacement is working now.
result <- z$findElement(using = 'xpath',"//*[contains(text(),'the deal” of hosting major sporting')]")
In above command the reference String have special character the deal” so ,R gave the Error as
Error: Summary: NoSuchElement
Detail: An element could not be located on the page using the given search parameters.
class: org.openqa.selenium.NoSuchElementException
but the reference element found in the particular URL.
I think the issue is with your syntax of 'contains' and the use of double quotes.
Check here below the correct syntax:
[text()[contains(.,'the deal of hosting major sporting')]]
also the error you are getting means that the element wasn't present at the time of checking. This can occur for a number of reasons.Two of the most common are: 1) you checked too early (i.e. a wait should be introduced instead of a delay).
wait.until(ExpectedConditions.elementToBeClickable(By.id<locator>));
2) Your xpath is wrong (most likely). Noticed you are using //* which means any node so as far as we know, you could be pointing to multiple elements. If you want a more specific xpath answer please post a screenshot with the html code of element you are trying to locate. But I'll take an educated guess on the below:
(your way improved without the ")
findElement(using = 'xpath',"//*[contains(text(),'the deal of hosting major sporting')]");
and if that does not work, go for this:
findElement(using = 'xpath',"//*[text()[contains(.,'the deal of hosting major sporting')]]");
Best of luck!
I'm very new to drupal and have to do some real quick small work. While going through the documentation at https://www.drupal.org/docs/8/theming/twig/functions-in-twig-templates, I saw string parameter to url() function.
{{ 'View all content'|t }}
what is the value that url() is taking?
Infact, i'm trying to get relative path. I used
Solutions
But, it didn't work for me because {{directory}} changed each time and led to url append. Is there any best practices? Thank you for suggestions.
When adding a URL into a string, for instance in a text description, core recommends we use the \Drupal\Core\Url class. This has a few handy methods:
Internal URL based on a route - Url::fromRoute(), Example: Url::fromRoute('acquia_connector.settings')
Internal URL based on a path - Url::fromInternalUri(), Example: Url::fromInternalUri('node/add')
External URL - Url::fromUri, Example: Url::fromUri('https://www.acquia.com')
The last two methods are very similar, the main difference is, that fromInternalUri() already assumes an 'internal:' prefix, which tells Drupal to build an internal path. It's worth reading up on what prefixes are supported, for instance the ':entity' prefix can help in building dynamic URIs.
When you need to constrict and display the link as text you can use the toString() method: Url::fromRoute('acquia_connector.settings')->toString().
If you need additional information please ask.
I can think of workarounds on how to get this working however I'm interested in finding out if there's a solution to this specific problem.
I've got a go program which requires a json string arguement:
go run main.go "{ \"field\" : \"value\" }"
No problems so far. However, am I able to run from the command line if one of the json values is another json string?
go run main.go "{ \"json-string\" : \"{\"nestedfield\" : \"nestedvalue\"}\" }"
It would seem that adding escape characters incorrectly matches up the opening and closing quotes. Am I minuderstanding how this is done or is it (and this is the side I'm coming down on) simply not possible?
To reiterate, this is a question that has piqued my curiosity - I'm aware of alternative approaches - I'm hoping for input related to this specific problem.
Why don't you just put your json config to the file and provide config file name to your application using flag package
Based on the feedback from wiredeye I went down the argument route instead. I've modified the program to run on:
go run main.go field:value field2:value json-string:"{\"nestedfield\":nestedvalue}"
I can then iterate over the os.Args and get the nested json within my program. I'm not using flags directly as I don't know the amount of inputs into the program which would have required me to use duplicate flags (not supported) or parse the flag to a collection (doesn't seem to be supported).
Thanks wiredeye
Context: ASP.NET MVC running in IIS, with a a UTF-8 %-encoded URL.
Using the standard project template, and a test-action in HomeController like:
public ActionResult Test(string id)
{
return Content(id, "text/plain");
}
This works fine for most %-encoded UTF-8 routes, such as:
http://mydevserver/Home/Test/%e4%ba%ac%e9%83%bd%e5%bc%81
with the expected result 京都弁
However using the route:
http://mydevserver/Home/Test/%ee%93%bb
the url is not received correctly.
Aside: %ee%93%bb is %-encoded code-point 0xE4FB; basic-multilingual-plane, private-use area; but ultimately - a valid unicode code-point; you can verify this manually, or via:
string value = ((char) 0xE4FB).ToString();
string encoded = HttpUtility.UrlEncode(value); // %ee%93%bb
Now, what happens next depends on the web-server; on the Visual Studio Development Server (aka cassini), the correct id is received - a string of length one, containing code-point 0xE4FB.
If, however, I do this in IIS or IIS Express, I get a different id, specifically "î“»", code-points: 0xEE, 0x201C, 0xBB. You will immediately recognise the first and last as the start and end of our percent-encoded string... so what happened in the middle?
Well:
code-point 0x93 is “ (source)
code-point 0x201c is “ (source)
It looks to me very much like IIS has performed some kind of quote-translation when processing my url. Now maybe this might have uses in a few scenarios (I don't know), but it is certainly a bad thing when it happens in the middle of a %-encoded UTF-8 block.
Note that HttpContext.Current.Request.Raw also shows this translation has occurred, so this does not look like an MVC bug; note also Darin's comment, highlighting that it works differently in the path vs query portion of the url.
So (two-parter):
is my analysis missing some important subtlety of unicode / url processing?
how do I fix it? (i.e. make it so that I receive the expected character)
id = Encoding.UTF8.GetString(Encoding.Default.GetBytes(id));
This will give you your original id.
IIS uses Default (ANSI) encoding for path characters. Your url encoded string is decoded using that and that is why you're getting a weird thing back.
To get the original id you can convert it back to bytes and get the string using utf8 encoding.
See Unicode and ISAPI Filters
ISAPI Filter is an ANSI API - all values you can get/set using the API
must be ANSI. Yes, I know this is shocking; after all, it is 2006 and
everything nowadays are in Unicode... but remember that this API
originated more than a decade ago when barely anything was 32bit, much
less Unicode. Also, remember that the HTTP protocol which ISAPI
directly manipulates is in ANSI and not Unicode.
EDIT: Since you mentioned that it works with most other characters so I'm assuming that IIS has some sort of encoding detection mechanism which is failing in this case. As a workaround though you can prefix your id with this char and then you can easily detect if the problem occurred (if this char is missing). Not a very ideal solution but it will work. You can then write your custom model binder and a wrapper class in ASP.NET MVC to make your consumption code cleaner.
Once Upon A Time, URLs themselves were not in UTF-8. They were in the ANSI code page. This facilitates the fact that they often are used to select, well, pathnames in the server's file system. In ancient times, IE had an option to tell whether you wanted to send UTF-8 URLs or not.
Perhaps buried in the bowels of the IIS config there is a place to specify the URL encoding, and perhaps not.
Ultimately, to get around this, I had to use request.ServerVariables["HTTP_URL"] and some manual parsing, with a bunch of error-handling fallbacks (additionally compensating for some related glitches in Uri). Not great, but only affects a tiny minority of awkward requests.