I'm running Mediawiki 1.34 and i customized the PluggableAuth login button text using $wgPluggableAuth_ButtonLabelMessage = 'Login with ABC credentials' ;.
But, it is adding a weird character to the beginning and end of the text. Is that normal, can i get rid of them?
My Mediawiki is running on a Debian 10 box (with LDAP) and i get the same result whether i use Chrome, Firefox, or IE.
That variable takes a message key, not plain text. If you don't care about internationalization at all, you could set it to new RawMessage( 'Login with ABC credentials' ); otherwise set it to something like 'mysite-pluggableauth-button' and then you can (alongside a number of other methods) provide the text via the MediaWiki:mysite-pluggableauth-button/<language code> wiki pages.
This documentation shows that i should have used $wgPluggableAuth_ButtonLabel = 'Login with ABC credentials'; instead of using $wgPluggableAuth_ButtonLabelMessage.
Related
I'm trying to insert an e-mail address with the ckeditor. After I saved my content element (text&media), the source code showing the ckeditor looks fine
some#mailaddress.com
But when I visit the webpage only the following is visible:
some(at)mailaddress.com
I found out, that the problem is the spam protection. If I enable
config.spamProtectEmailAddresses = 1
The mail not rendered anymore. It's working without protection, but I want to use it.
Thank you for help.
I have performed the following test (TYPO3 8.7.7) and CKEditor with full configuration:
1) config.spamProtectEmailAddresses = 1 and config.spamProtectEmailAddresses_atSubst = [at]
2) Create a CE text with image
3) write test email into the text editor and then use the "link" button to add an email address
3.1) write test#email.it into the text editor and then use the "link" button to add an email address
3.2) write test#email.it into the text editor without adding the link
Results
3.1) the href attribute of the link is encrypted (javascript:linkTo_UnCryptMailto('...');)
3.2) the href attribute of the link is encrypted (javascript:linkTo_UnCryptMailto('...');) while the visible text does not become test[at]email.it
3.3) no link is added to the text; the visible text does not become test[at]email.it
Could you tell us if you installed some CKEditor plugins or some write some detail of your configuration?
I found it out!
The problem was at my fluid template. I wrapped the {CONTENT} variable with
<f:format.html parseFuncTSPath="lib.parseFunc">{CONTENT}</f:format.html>
It's working now after I changed this to
<f:format.raw>{CONTENT}</f:format.raw>
but if you use <f:format.raw>, the email address is not spam protected anymore. Thats not, what you wanted, isn't it?
I have the problem, the <pre>-tag is html encoded and only works in <f:format.raw>, but then, the email addresses are plain.
Martin
I'm in an odd situation where I need to check, via a test, that a currency symbol is being properly displayed on our web page.
We've been running into issues where sometimes the unicode alphanumeric value is showing up on the page instead of the actual currency symbol itself.
Is there a way to check for something like this? Like with some type of visual checking library, or through javascript?
The answer to this issue was to specifically copy and paste the unicode character I was looking to test against into my text editor.
So using the Protractor framework, I would find my css element, and if I have a known price of 17.99 that should be returning, my test function would return:
return expect(myPriceElement.getText()).to.eventually.equal(£17.99);
If on my webpage, £17.99 shows up, then my test will pass
Kind of a strange one, but in my views I have a tick (✔) and a cross (×) used as links (in lieu of images). Is there any way of finding these elements and testing them using RSpec and Capybara-webkit, or should I try and target say the title attribute instead and ignore this route?
My test in question looks like this:
context "casting a vote", js: true do
before do
sign_in user
click_link '✔'
sleep 0.2
end
it { should have_content("Vote cast!") }
end
The failure message I get is (predictably):
Failure/Error: click_link "raw('✔')"
Capybara::ElementNotFound:
Unable to find link "raw('✔')"
Thanks in advance for your help.
Capybara doesn't see the HTML, it runs thru the DOM, which then sees the actual values those things encode. You must send the raw code as a UTF-{8,16} string containing the code point itself.
Most languages would present an HTML '✔' as "\u10004", so try that.
I'm afraid this is highly specific, so please bear with me and read carefully.
The problem:
Open a PDF file, select and copy some text that contains line breaks and paste it into a TinyMCE textarea in the Google Chrome browser. Then delete any line break and insert a space at the same point: the space that is added is non-breaking even though I used a regular "space bar" key stroke in TinyMCE.
How do I know there is a non-breaking space?
You can click the "show invisible characters" button on the first row of my TinyMCE implementation (see link below). Remember that with TinyMCE your must turn that option Off and On again every time you modify the text to see the changes.
The non-breaking spaces will appear in orange, normal spaces appear normally.
What I have found so far:
If I delete the character that comes after the line break and then type that character again, I can insert a normal space. The problem seems to be attached to that character.
If I delete the character occuring before the line break, the problem persists, i.e. when I delete the space and type a new space it is still a non breaking space.
Also when I save the text to the MySQL database, and read it again in TinyMCE, the problem still occurs, which reinforces my impression that the "hidden" character is attached to the letter following the line break (there is no saving on the test page of course).
Replicating it
You could of course try it yourself, but here is my testbed for you: http://www.roseback.com/test/tinymce4.html
I have tested it with many PDF files that we receive from graphic designers, from many products and eras. These PDFs are the files that are used for printing and there is no problem with those files for that use.
I uploaded a sample file here: http://www.roseback.com/test/languedoc.pdf. Test with the first paragraph starting with "Ce film exceptionnel".
However I have also tested random PDF files from the web and replicated the problem every time. So if you try with your own files and can't replicate, that might be interesting.
Environment:
Web page: the page is in HTML5, in UTF-8.
On the original page, the page is served via PHP and the textarea content comes from a MySQL 5.1 DB. The DB connection is set to UTF-8 in PHP, the content of the table and of the text field is in utf8_unicode_ci
On the test page there is no content and no saving, so no DB is involved.
Browser: Chrome. Does not happen in Firefox or Opera (not tested elsewhere)
TinyMCE: version 3 and version 4 (both standard version, not jQuery)
OS: on Windows 7 Pro 64 bit and also on Windows XP Pro 32 bit
I would appreciate any feedback, even simple confirmation / replication of the problem.
Hmm, i think what you observe has something to do with the fact that tinymce inserts non breaking spaces instead of spaces. Tinymce needs to so this in order to avoid that the browser shows more than one space concurrently entered as one single space (this is the default browser behaviour).
You can verify this by inserting more than one space and then have a look at the non-visible characters.
I am testing an ASP.NET web form which needs to filter out null characters from input.
To test this functionality, how can I actually type a null character in the html form? I've tried Alt+0 but it does not work.
I know I can do it in a GET request by using "%00" in the URL. However, I want to do it in a form POST.
I was able to do this using TamperData Firefox plugin.
https://addons.mozilla.org/en-US/firefox/addon/tamper-data/
When given the Tamper Popup I typed "%00" in the Post Parameter Value field.
Still, I cannot find a way to type a null character just using the keyboard.
my suggestion would be to write the null character to an html element you would like it in
ex:
document.getElementByID("my_null_tag").innerHTML += "\0"
You can use an HTML entity. Not fully sure of how many zeroes are required but:
For an arbitrary Unicode character it's easier to use the hexadecimal notation. E.g., ㍝ prints ㍝ wich is U+335D.
Update: This question is pretty tricky indeed. I've managed to insert a null character inside an HTML document (using a server-side script and verified with an hexadecimal editor). As expected, there is no difference with the HTML entity, which can be either or . But the browser does not send the character in the post request (tested with Firefox and Firebug): it sends %EF%BF%BD, which is REPLACEMENT CHARACTER' (U+FFFD). Exactly, it sends the interrogation mark in a box that's used to print the null in the document (given that null is not printable).
My guess is that your testers need to script the task.
<html>
<body onload='document.forms[0].submit();'>
<form method="post" action="http://localhost/test.asp" >
<input type="hidden" name="param" value="%00">
</form>
</body>
</html>
Use AJAX to submit the form. I.e. paste something like this in the address bar instead:
javascript:(function(){var xhr=new XMLHttpRequest();xhr.onreadystatechange=function(){if(this.readyState==4){document.write(this.responseText)}};xhr.open("POST",'/form',true);xhr.send("\0");})()
Here it is unwrapped, so you can actually see it:
(function() {
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function () {
if (this.readyState == 4) {
document.write(this.responseText);
}
};
xhr.open("POST", '/form', true);
xhr.send("\0");
})()
There are some limitations to this, of course, since it just blindly replaces the content of the current page with whatever it got back. But this might be enough to tell if something went wrong or not.
This answer from Jonathan H. didn't really work for me, but it did put me on the right path. What did work was to set the .value attribute of the HTML element (via the browser dev tools console), and then submit the form.
document.getElementByID("element-id").value = "some text with a null byte\0"
A Latin character O with a slash through it is often acceptable as a symbol for Null/Nul (or blank if you prefer). If you are using database-driven applications you'll want to sanitize this symbol to replace with null or blank, depending on your needs.
How to do it:
ALT + 0216 in your favorite editor should give you Ø - which is, for this display purpose, Null.
Then, as an example and a best practice, you'll sanitize the form submission before it gets passed to the database.
Example Case:
If feeding a database-driven PHP site, your sanitation of this specific character this might look something like...
$dbstring = str_replace(Ø,NULL); and the value will be NULL
Or try...
$dbstring = str_replace(Ø,""); and the value will be BLANK
! alternatively, you may want to do this display with the HTML entity codes, which I mention below.
Alt + 0216 explained
If using a normal 104-key keyboard with English (American) set as your primary language, hold down the ALT key, and while holding, use the NUMBER PAD keys to enter 0216. Then release the ALT key, and your character should appear.
*This is primarily a Windows method. Macintosh, (X)nix and bsd users, you will probably be stuck using the HTML entity codes.
Special note: use of the top-of-keyboard numbers doesn't work.
If you are on a laptop or other device that makes this difficult or impossible. try an alternative: Use the HTML entity codes:
Ø = Ø (usually for null)
ø = ø (could be used, but the upper-case version seems more appropriate.)
Other thoughts that might be helpful: Nul vs Null vs Blank - They fundamentally mean the same thing, but different programming languages use or require these differently. (There's others too, like NULPTR for Null Pointer.)
The point I'm trying to make with NUL/NULL, is that the submitted variable 'doesn't exist' or simply 'wasn't there at all'. In most contexts, you can simply call this "Null" and be understood.
Some database systems treat Blank and NULL as the same thing. Others, Blank is actually an empty value, whereas NULL is no value at all (like mentioned above.)
Hopefully this helps in building the view you're looking for.