Welcome to the MediaWiki Support desk, where you can ask MediaWiki questions!
(Read this message in a different language)
|
|---|
|
|
I am newbie, and I made a small mod that gives haste after use CloakandDager if I was invisible, but haste apper anyway.
Self:IF(Self:Invisible):HASTED,100,1;
Where is mistake?
Also how to give out an action point if I am invisible and use CloakandDager?
I am setting up a mediawiki on a raspberry pi. We are running the browser and desktop in a very locked down state where no browser controls are visible or accessible. This works, except when users click on an image on the image's description page. This opens the image all by itself outside of the mediawiki navigation environment. The problem is that there is no way to escape from that state, since there are no links back out. Can anyone suggest a solution? It might be changing something so the image isn't a link, or is a link to the description page itself. Or it might be adding a link back to the image only page. Or maybe someone has an even better idea? Thanks in advance!Tenbergen (talk) 00:32, 10 December 2023 (UTC)
Can you clarify what you mean by "This opens the image all by itself outside of the mediawiki navigation environment"? Do you mean it opens something like https://upload.wikimedia.org/wikipedia/commons/thumb/d/dd/MediaWiki-2020-logo.svg/270px-MediaWiki-2020-logo.svg.png, instead of https://www.mediawiki.org/wiki/File:MediaWiki-2020-logo.svg?
It should be possible to disable or change the image link using [[MediaWiki:common.js]]
Yes, that is what I meant. You are no doubt correct that it can be changed with mediawiki:commons.js, but I am not sure how. Somewhere online suggested the following but it didn't do the trick.
document.addEventListener("DOMContentLoaded", function() {
if (mw.config.get('wgNamespaceNumber') === 6) { // Check if it's a file namespace
var filePageImages = document.querySelectorAll('#file img'); // Select images within the file description area
filePageImages.forEach(function(img) {
img.addEventListener('click', function(e) {
e.preventDefault(); // Prevent the default action
window.location.href = mw.config.get('wgServer') + mw.config.get('wgScriptPath'); // Redirect to the main page
});
});
}
});I ended up using the following to change the URL of the link to stay on the image description page instead of going to the image file itself. There are probably better ways that would disable the click function altogether, but I don't know hooks or php well enough to work those out.
#--
# Change the click behaviour on the image description pages to stay on that page
# Default behaviour to link to the image itself would leave the kiosk in an unbrowsable state
# since it doesn't have a back button.
$wgHooks['OutputPageBeforeHTML'][] = function( $out, &$text ) {
if ( $out->getTitle()->getNamespace() == NS_FILE ) {
$newUrl = ""; // Replace with the URL you want the image to link to
$out->addScript(
"<script type=\"text/javascript\">
document.addEventListener('DOMContentLoaded', function() {
var imageLink = document.querySelector('.fullImageLink a');
if (imageLink) {
imageLink.href = '" . addslashes($newUrl) . "';
}
});
</script>"
);
}
return true;
};
#--Hi, I am a member of the Internet Movie Firearms Database, a wiki about firearms in films, television, and video games powered by MediaWiki.
During an IMFDB server update last year, a strange error occurred where all the page titles with "non-standard" ASCII characters (mainly letters with diacritics) were broken; the pages became prefixed with "Broken/", and the non-standard characters were replaced with "\x(ASCII code here)".
We have been trying to fix the titles via manual moving (example), but it's a slow and inefficient process, and there are also many files (and pages in other namespaces) that have been broken by the update.
Me and most of the staff on IMFDB are not experts on MediaWiki science, so I would like to ask, what caused this error? What can be done to fix it quickly?
P.S.: I was recently promoted to administrator on IMFDB, and I am in contact with the head developer of IMFDB. I should be able to provide additional details by contacting them.
This is usually caused by manual:cleanupTitles.php which is not usually part of the update process.
It looks like the issue was an iso-8859-1 vs utf-8 encoding issue. Sometimes this is caused by changing db charset settings or by making a mistake when restoring a backup.
You can potentially make a bot to fix this, but i dont know any preexisting ones.
So, I am now an IMFDB admin, and over the last couple of months, our (i.e. IMFDB staff and the members of MediaWiki community who have been helping out on the unofficial MediaWiki Discord) investigation into the title errors has revealed many deeper and stranger problems.
All of our investigations have ended in dead ends, and I think we might need to have our Wiki be reviewed by professional MediaWiki developers to see just what went wrong with it.
> Additionally, the fact that no page move is recorded in the page histories is uncharacteristic of CleanupTitles.php.
That would be normal for cleanupTitles.php. cleanupTitles.php does not normally log page moves.
So for broken image titles.
It does look like there is issues with latin1 vs utf-8 in the database not just for page titles, but also for the img_name field in the database. (You can see this at https://www.imfdb.org/api.php?action=query&prop=info&list=allimages&aifrom=Ges&ailimit=2&aito=Ger&aidir=descending - Note how one of them has %E4 in the url while the other is %C3%A4. %E4 is the character ä in latin1 encoding, where %C3%A4 is how you do it in UTF-8. (If you also notice \u00E4, just to be extra confusing that is how json writes the UTF-8 version of ä, where \ufffd is how json writes invalid character). cleanupImages.php may be able to fix this.
It looks like there is also still a page associated with the old name, but mediawiki does not want to view it directly giving an exception. . You can still view it in the API . So clearly if cleanupTitles.php was run, it didn't fully work as we still have invalid page titles in the database.
Similarly, broken redirects show's invalid characters in the redirect targets - https://www.imfdb.org/api.php?action=query&list=querypage&qppage=BrokenRedirects&qplimit=max . The actual text content of the redirect pages use proper utf-8, so it looks like the redirect database table just got its charsets munched up. This could possibly be fixed by running the script refreshLinks.php.
So my general advice would be:
And then see what your wiki looks like. Taking a backup in case that is not an improvement. If this was earlier in the process, i would say revert to before the upgrade, try to figure out what happened to cause the charset confusion and then reupgrade, but at this point people have been editing, so i think it makes more sense to just go from here.
p.s. If you are looking for professional consulting, there is a list at Professional_development_and_consulting
We ran refreshLinks.php on a backup copy of IMFDB, and it didn't work; the same erroneous results still showed up, with no changes to any of them. We're planning on reverting our backup server to the pre-upgrade version to see what's different, and we want some advice as to what we should check or if we should try something different.
Did you run it as the last step? It would only work after running cleanupImages.php
We tried running all the scripts again. We forgot to mention this, but there was an error while running refreshlinks.php (both this time and the last time):
MediaWiki\Revision\RevisionAccessException from line 1296 of /var/www/w/includes/Revision/RevisionStore.php: Main slot of revision not found in database. See T212428.
#0 /var/www/w/includes/Revision/RevisionStore.php(1224): MediaWiki\Revision\RevisionStore->constructSlotRecords()
#1 /var/www/w/includes/Revision/RevisionStore.php(1220): MediaWiki\Revision\RevisionStore->loadSlotRecords()
#2 /var/www/w/includes/Revision/RevisionStore.php(1335): MediaWiki\Revision\RevisionStore->loadSlotRecords()
#3 [internal function]: MediaWiki\Revision\RevisionStore->MediaWiki\Revision\{closure}()
#4 /var/www/w/includes/Revision/RevisionSlots.php(175): call_user_func()
#5 /var/www/w/includes/Revision/RevisionSlots.php(117): MediaWiki\Revision\RevisionSlots->getSlots()
#6 /var/www/w/includes/Revision/RevisionRecord.php(192): MediaWiki\Revision\RevisionSlots->getSlot()
#7 /var/www/w/includes/Revision/RevisionRecord.php(175): MediaWiki\Revision\RevisionRecord->getSlot()
#8 /var/www/w/includes/page/WikiPage.php(805): MediaWiki\Revision\RevisionRecord->getContent()
#9 /var/www/w/maintenance/refreshLinks.php(236): WikiPage->getContent()
#10 /var/www/w/maintenance/refreshLinks.php(188): RefreshLinks->fixRedirect()
#11 /var/www/w/maintenance/refreshLinks.php(84): RefreshLinks->doRefreshLinks()
#12 /var/www/w/maintenance/doMaintenance.php(107): RefreshLinks->execute()
#13 /var/www/w/maintenance/refreshLinks.php(496): require_once('/var/www/w/main...')
#14 {main}
huh.
That might be consistent with the updater not running fully. I'm not sure.
So, head bureaucrat bunni is proposing that our single-leap update from version 1.19 to 1.35 could have broken the database and caused all these weird coding issues; he proposes that we should restore a backup and then update from 1.19 to 1.2 then to 1.3.
Seems unlikely to me. Last time mediawiki changed encoding was version 1.5. It is most likely the encoding issues are at the layer brlow mediawiki.
Restoring from backup is probably the best way to go though, if doable.
Getting the same problem reported for topic " Malformed UTF-8 characters, possibly incorrectly encoded” after setting the language in the installation sequence.
Config:
XAMPP for OS X 8.2.4
msyql is listening on port 3306.
MediaWiki
PHP 8.2.4 is installed.
ICU 73.2 is installed (supports Unicode 15.0.0
Object caching is not enabled.
Found ImageMagick: /usr/local/bin/convert
Found the Git version control software: /usr/bin/git
Host - 127.0.0.1
Port - 8080
XAMPP control phpmyadmin loads just fine, connects to db server, can create DB, user etc.
I tweaked the exception string & to add the full text passed into the MagicWordArray function:
[ZX28RZpT3IFBxM9dbTF-YQAAAAY] … page=Welcome Exception: preg_match_all error 4: Malformed UTF-8 characters, possibly incorrectly encoded ...
You should have received … /�__�.invalid
…
The bracketed prefix changes on each reload.
So the host:port isn’t getting decoded properly for some reason?
I had to install intl for php 8.2.4 by hand, so I don’t know if that could come into it. Seems unlikely.
Got stuck on Connect Database;
[92c66aff7b86e27481dece49] /mywiki/mw-config/index.php?page=DBConnect Exception: preg_match_all error 4: Malformed UTF-8 characters, possibly incorrectly encoded
Backtrace:
from C:\xampp\htdocs\mywiki\includes\MagicWordArray.php(319)
#0 C:\xampp\htdocs\mywiki\includes\parser\Parser.php(4116): MagicWordArray->matchAndRemove(string)
#1 C:\xampp\htdocs\mywiki\includes\parser\Parser.php(1636): Parser->handleDoubleUnderscore(string)
#2 C:\xampp\htdocs\mywiki\includes\parser\Parser.php(724): Parser->internalParse(string)
#3 C:\xampp\htdocs\mywiki\includes\language\MessageCache.php(1374): Parser->parse(string, MediaWiki\Page\PageReferenceValue, ParserOptions, boolean)
#4 C:\xampp\htdocs\mywiki\includes\Status.php(331): MessageCache->parse(string, MediaWiki\Page\PageReferenceValue, boolean, boolean, NULL)
#5 C:\xampp\htdocs\mywiki\includes\installer\WebInstaller.php(1044): Status->getHTML()
#6 C:\xampp\htdocs\mywiki\includes\installer\WebInstallerDBConnect.php(41): WebInstaller->showStatusBox(Status)
#7 C:\xampp\htdocs\mywiki\includes\installer\WebInstaller.php(271): WebInstallerDBConnect->execute()
#8 C:\xampp\htdocs\mywiki\mw-config\index.php(82): WebInstaller->execute(array)
#9 C:\xampp\htdocs\mywiki\mw-config\index.php(40): wfInstallerMain()
#10 {main}
Certainly weird. Maybe could be caused if the database returned an error that was not encoded as valid utf-8.
I don't know. I followed everything exactly step by step from the xampp manual for mediawiki.
As a hack, you could try in includes/installer/WebInstaller.php on around line 4042 replace the line
$html = $status->getHTML();
with:
$html = UtfNormal\Validator::cleanUp( $status->getHTML() );
If that actually fixes it, you should get a more descriptive message. Please let me know if that works, and what the more descriptive error message is.
There's only ~1200 lines in WebInstaller.php, but I found the line of code and replaced it; it didn't do anything.
Oh, i guess it should be line 1042.
I suppose you could try doing:
$html = htmlspecialchars( UtfNormal\Validator::cleanUp( print_r( $status->getErrorsArray(), true ) ) );
instead. Not sure if that will work.
Super weird. Some sort of locale issue in the error i guess.
But for actual cause, what did you use as your db server?
The error message "getaddrinfo for local/localhost failed" is concerning... Are you using "local/localhost" (with a literal /) as the hostname for the database connection?
The server name outside of PhpMyAdmin should be "localhost", or even better, "127.0.0.1" on Windows. See Manual:$wgDBserver
I set it to 127.0.0.1....
Array ( [0] => Array ( [0] => config-connection-error [1] => Cannot access the database: :real_connect(): (HY000/1045): Access denied for user 'admin'@'localhost' (using password: YES) ) )
Well, that means you didn't provide the correct database credentials for user admin
Title of the Wiki "Notes" is not showing when I'm logged out. I have these lines in LocalSettings.php:
$wgSitename = "Notes";
$wgMetaNamespace = "Notes";
And I thought I removed the logo but sometimes I see the logo too. How can I fix these?
When you write code to chase donors away, and you write code that promises to not stick your PITA donation appeals in my face for a week and it pops up the very next time I look something up on Wikipedia, it's obvious that you're not testing your code.
I've been sending donations to Wki for a decade or two, since I've been relying on Wikimedia since nearly it's inception. If you want me and other like me to stop contributing keep this brutal donor appeals going and continue to make promises that don't occur because you dont test your code.
As a retired SPAWAR Systems Engineer who ran testing on/within some of the largest integrated systems, it's disappointing to see this kind on disfunction in one of my favorite sources.
Edward Eric Matus, ETC USN ret. eericmatus@gmail.com
Wiki has to send receipts to donors for use in tax returns. How hard would it be to add a database and direct the donor IDs into it and then add a subroutine to ensure you do not send your obnoxious appeals to people who regularly donate. That would be good social networking/marketing.
> How hard would it be to add a database and direct the donor IDs into it and then add a subroutine to ensure you do not send your obnoxious appeals to people who regularly donate.
Umm, have you tried creating an account and logging in? Maybe the world you want already exists.
My wiki was running a older version 25 so I upgraded to version 35LTS and about 90% of the articles disappeared including the main page. Looking in the database it looks like all the information is still actually there.
Long story short, I upgraded one version at a time which was successful until I hit version 1.33.1 where the majority of articles have disappeared and also the images have as well.
The images are on the server and I can access them via direct URL. but they do not load on the wiki page. When looking at the files section there is only about 15 images listed. Half of them are ones which I uploaded last week and several were from the original wiki in 2006. However in trying to fix this problem has now broken the thumbnails. This happened after I change the folder permissions to 777.
I keep seeing people saying run the scripts..
php maintenance/update.php
php maintenance/cleanupUsersWithNoId.php --prefix '*' --table revision
php maintenance/migrateActors.php
php maintenance/rebuildImages.php
But this did not help.
After several hours of looking around the Internet I came across this article..
https://www.mediawiki.org/wiki/Topic:Vy4x2pb18ebrvqix
Where it says run..
INSERT INTO revision_actor_temp (revactor_rev, revactor_actor, revactor_timestamp, revactor_page) SELECT rev_id, 1 as actor, rev_timestamp, rev_page FROM revision WHERE rev_id NOT IN (SELECT revactor_rev FROM revision_actor_temp);
Running that went from 4949 rows and 12489 after.
Now this did seemingly bring back the majority of the pages. The main page was still missing but when I clicked edit the information was there. So I saved the page and then it was working again afterwards. However I still have the problem with the images.
I have seen some posts talking about..
$wgHashedUploadDirectory = false;
But true or false makes no difference. I did try some other things in the file to no avail. I also tried deleting it and resetting up the wiki and re-uploading the settings file. But this did not change anything either.
I'm not really sure where to go from here now. It seems like something is fundamentally broken during the update.
If anyone has any suggestions please let me know because after fighting with this all week I really don't know what to do now.
The only problem I found when running the update.php is what others seem to get stuck with , and never seems to be a solution.
User name "Exxos" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.
User name "Adolobe" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.
User name "Dazarz" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.
User name "Tin" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.
User name "Docrv" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.
User name "Rockyone" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.
User name "Rainwarrior" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.
User name "Steelz" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.
User name "Bikerbob" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.
User name "Bigclaw" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.
User name "Tomh" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.
User name "Panthen10" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.
User name "Magikgimp" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.
User name "Ragnar76" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.
I had to delete about 9 million spam users. So not sure where these names are all coming from now. There are 56 users left in the table. I wrote a script to verify they all had posts somewhere on the wiki. Though one listed is my account "EXXOS" which exists plus a lot of users which don't exist.
I ran the cleanupUsersWithNoId.php , it output some stuff, but all the problems remain. If I run update.php it just goes back to telling me to run cleanupUsersWithNoId.php , which I did multiple times.
As for the images. It seems if I try and upload the same file, it won't let me do it. Says already exists. So the wiki knows the file is there and yet it doesn't show on the wiki itself. Uploading a new image is fine and shows fine also. The only thing I can do is figure out how the wiki deals with images and see if I can figure anything out that way.
> php maintenance/cleanupUsersWithNoId.php --prefix '*' --table revision
Why --table revision? Try running without that.
It doesn't seem to matter what I put..
php maintenance/cleanupUsersWithNoId.php --prefix '*' --force
Beginning cleanup of revision
... rev_timestamp=20231128214153 rev_id=1000000026
Completed cleanup, assigned 0 and prefixed 0 row(s)
Beginning cleanup of archive
... ar_id=100
... ar_id=200
... ar_id=300
... ar_id=400
... ar_id=500
... ar_id=600
... ar_id=700
... ar_id=800
... ar_id=900
... ar_id=1001
... ar_id=1102
... ar_id=1208
... ar_id=1324
... ar_id=1426
... ar_id=1528
... ar_id=1633
... ar_id=1739
... ar_id=1843
... ar_id=1951
... ar_id=2055
... ar_id=2156
... ar_id=2256
... ar_id=2365
... ar_id=2465
... ar_id=2584
... ar_id=2688
... ar_id=2788
... ar_id=2888
... ar_id=3016
... ar_id=3147
... ar_id=3253
... ar_id=3388
... ar_id=3497
... ar_id=3597
... ar_id=3709
... ar_id=3817
... ar_id=3933
... ar_id=4043
... ar_id=4143
... ar_id=4252
... ar_id=4367
... ar_id=4479
... ar_id=4587
... ar_id=4700
... ar_id=4805
... ar_id=4907
... ar_id=5007
... ar_id=5107
... ar_id=5207
... ar_id=5307
... ar_id=5407
... ar_id=5507
... ar_id=5607
... ar_id=5707
... ar_id=5807
... ar_id=5907
... ar_id=6007
... ar_id=6107
... ar_id=6207
... ar_id=6307
... ar_id=6407
... ar_id=6507
... ar_id=6607
... ar_id=6650
Completed cleanup, assigned 0 and prefixed 0 row(s)
Beginning cleanup of logging
... log_timestamp=20081014215605 log_id=501
... log_timestamp=20081014215622 log_id=601
... log_timestamp=20081014215638 log_id=701
... log_timestamp=20081014215648 log_id=801
... log_timestamp=20081014215707 log_id=901
... log_timestamp=20081014215726 log_id=1001
... log_timestamp=20081014215741 log_id=1101
... log_timestamp=20081014215751 log_id=1201
... log_timestamp=20081014215803 log_id=1301
... log_timestamp=20081014215815 log_id=1401
... log_timestamp=20081014215830 log_id=1501
... log_timestamp=20081014215844 log_id=1601
... log_timestamp=20081014215907 log_id=1701
... log_timestamp=20081014215923 log_id=1801
... log_timestamp=20081014215931 log_id=1901
... log_timestamp=20231128214153 log_id=1826850
Completed cleanup, assigned 0 and prefixed 0 row(s)
Beginning cleanup of image
... img_timestamp=20231128214153 img_name=Hydra3333.jpg
Completed cleanup, assigned 0 and prefixed 0 row(s)
Beginning cleanup of oldimage
... oi_name=ST_Motherboard_C070789-001_Rev_C_exxos2.jpg oi_timestamp=20080927121714
... oi_name=Ym2149.png oi_timestamp=20060913135635
Completed cleanup, assigned 0 and prefixed 0 row(s)
Beginning cleanup of filearchive
... fa_id=32
Completed cleanup, assigned 0 and prefixed 0 row(s)
Beginning cleanup of ipblocks
... ipb_id=236
... ipb_id=3593
... ipb_id=4312
Completed cleanup, assigned 0 and prefixed 0 row(s)
Beginning cleanup of recentchanges
... rc_id=7352200
... rc_id=7352269
Completed cleanup, assigned 0 and prefixed 0 row(s)
Then....
php maintenance/update.php > update9.txt &
User name "AciYc9" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.
User name "LopU7l" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.
User name "KiqAoj" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.
User name "CytZ92" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.
User name "QpuJ2e" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.
User name "Ramya" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.
User name "Zhangpeng" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.
etc
The image problems are weird.
php maintenance/checkImages.php
170px-Megan_Fox_71.jpg: missing
Dizzy.png: missing
Hydra3333.jpg: missing
Good images: 31/34
Thing is, 2 of those images actually show up on the wiki. Its like the wiki is using the wrong table for the images. But there are over 800 in the images table and the recent ones I uploaded work. Oddly a couple of older images are showing up in the mainpage now.
All the paths are correct and accessible direct in the browser. The file hashes match all the folders in the images folder on the server.
So I've deleted all the rows for one particualr file in the images/page tables and anywhere else I can find the filename I am working on, and still the wiki says the file exists. I've even deleted all the same filenames out of the images folder and thumbs folder.
At this point I am looking at the getExistsWarning function in Specialupload.php trying to figure out what the full path is that its "finding" the image file at, but I can't seem to work out anything but what the actual filename is, which I know already.
So does anyone know how to patch the function to output the FULL path its looking for the file at ? It may give me some clues. Its "finding" the file somewhere, but if its seemingly not in the tables anywhere or on the server as a file, WHERE is it finding the thing ?!
I also have the wiki debug logs enabled. All the SQL statements I ran them manually in phpmyadmin and all return "nothing".
I would not suggest to jump from 1.25 to 1.35 or even to 1.33, try to upgrade 1.25 -> 1.29 -> 1.31. Or something like that.
It seems Apache was causing a lot of these problems. It seems to store pages, even SQL data in a cache by itself somewhere. Restarting SQL doesn't change anything. But if I restart apache2 after SQL edits, things start behaving afterwards. Though on my main server I changed to Nginx anyway as Apache kept having various odd issues with no solution.
If using apcu as cache, what likely happened is you forced a cache clear by doing that.
