I am running MediaWiki 1.39.5. We have a Widget that loads projects information from OpenAIRE and make it available to all pages within our mediawiki setup. Widgets work perfectly fine. What we want is to do search over these loaded project information via MediaWiki search. However, The search provided by MediaWiki does not find these loaded information. We have tried advanced search but nothing happened. How can i search this data inside mediawiki? Do i need separate search function for this kind of data?
Extension talk:Widgets
MediaWiki search only has the data available in the wiki code of each page. Widgets load content from external sources on the browser, not on the server, and that's why MediaWiki search can't find it
Ahaan! so, what is the best way to perform search on this kind of data in mediawiki?
There's no way to do that. A bot or some other automatic process would need to fetch the data and store it on the wiki page directly instead of relying on external requests (widgets)
I am running MediaWiki 1.39.5 and recently switched to PHP 8.2.x (8.2.12 currently).
We have a Widget test page that loads sample Google presentation, Google document and Google Spreadsheet widgets.
All appear okay. However in the error_log we get:
[07-Nov-2023 23:12:33 UTC] PHP Warning: Undefined array key "width" in w/extensions/Widgets/compiled_templates/ba811dbfd89414d874993a209b5e2eb71ad14d2d_0.wiki.GooglePresentation.php on line 24 [07-Nov-2023 23:12:33 UTC] PHP Warning: Attempt to read property "value" on null in w/extensions/Widgets/compiled_templates/ba811dbfd89414d874993a209b5e2eb71ad14d2d_0.wiki.GooglePresentation.php on line 24 [07-Nov-2023 23:12:33 UTC] PHP Warning: Undefined array key "height" in w/extensions/Widgets/compiled_templates/ba811dbfd89414d874993a209b5e2eb71ad14d2d_0.wiki.GooglePresentation.php on line 25 [07-Nov-2023 23:12:33 UTC] PHP Warning: Attempt to read property "value" on null in w/extensions/Widgets/compiled_templates/ba811dbfd89414d874993a209b5e2eb71ad14d2d_0.wiki.GooglePresentation.php on line 25
I have gone through the individual Widget pages and purged the page so that the compiled templates are refreshed.
These seem to be indicative of something not compatible with PHP 8.2 changes or is some step required to recompile the template(s)?
I doubt it. Anyhow, MediaWiki is not compatible with PHP 8.2 either. Did the widget work with earlier versions of PHP, MediaWiki, and Widgets?
According to Compatibility#PHP MediaWiki support for PHP 8.0 and above started with 1.39.0. The recent 1.39.5 release announcement makes mention that "Various patches aimed at PHP 8.0, 8.1, and 8.2 support have been back-ported."
The Widget's work as far as the end-user knows. The PHP Warnings in the error_log are something I would expect the Extension:Widgets developers to address.
I don't know what your widget looks like and how it is used, so this is a wild guess, but the error messages read like the values for those parameters have not been specified. If those values were omitted, did you at least provide defaults or provided an 'if' condition to prevent such errors from occurring?
Returning to this... I had the same issue, recently. At some point, the Widget extension has become less forgiving when you do not set a value for a parameter defined in the widget, which will trigger the warning you encountered. Like I mentioned at the time, you can use an 'if' condition to get around this[1], but what I didn't know is that defaults (https://www.smarty.net/docs/en/language.modifier.default.tpl) no longer seem to work and will emit same error message. I used the REL1.39 branch of the extension, which installed version 1.4.2, and I am using PHP 8.0.
This no longer works:
<!--{$myparam|escape:'quotes'|default:'Nothing to see here'}
It looks like the issue began with the inclusion of modifier.allowedvalues.php, which does not check for defaults.
[1] For anyone looking for am example, this solution checks if the param is set at all and if it is, if the value is not 'empty', similar to how you would wiki templates
<!--{if ( isset($myparam) && $myparam!="" )}-->
<!--{$myparam|escape:'quotes'}-->
<!--{else}-->
Nothing to see here [optional default]
<!--{/if}-->
Hi, making a flashcard system on my wiki using SMW (flashcards are defined in pages and available in portals), the display is made with tabs with the input-radio trick (see for example : https://www.youtube.com/watch?v=oLqdy95LZSw ). So the html structure and css are in Widget:Flashcard.
But questions and answers may have links to pages (definitions...), images... in wikicode. And they are not rendered after being sent to the widget witch displays raw code.
Is it a way to render them ? Thanks
I would also like to know if it is possible to send wikicode through the extension to be rendered. It would open up much more flexibility in my use case.
Hi all,
I just want to make people aware that the twitter feed widget is not working anymore since September 10th. I have marked them as such in the list (crossed text through). They don't work anymore as twitter changed there method of how you can tab into your twitter feed and removed the old option to link to your twitter feed
I reported this as T207716.
Here is how mine works now, `id` is the Twitter user at:
* https://wiki.kiwix.org/wiki/Main_Page
* https://wiki.kiwix.org/wiki/Widget:Twitter
Widget code has been updated on MediaWikiWidgets.
Hello. Today I found this widget doesn't work. Please see example part in following page. As you can see, the example codes are not working.
Our wikis have a lot of widgets, some of which I'm seeing get recompiled into the compiled_templates directories many times per minute, even sometimes multiple times in a second. In that particular example, the only thing changing in the compiled code is the JS function name that is randomly generated by the call to PHP uniqid('', true). Is this probably something with how our Widgets are written, or perhaps about how they are used within templates and themselves use templates (it gets messy)? FWIW a while back I opened a Phabricator task on this.
Any thoughts on my question?
I would like to understand this better too for similar reasons.
Some links I found to be very helpful:
it looks like the extension is currently using ParserAfterTidy hook to decide this, which is probably not the most correct option. Something LinksUpdate related would be better (although have to be careful about asyncness of linksupdate)
I use a Windows laptop with XAMPP. After I installed this extension, I enabled FlaggedRevs. However, when I then tried to save a page that transcluded a widget, I got this Internal error:
[67a635e5d3c566814dbcfeab] /wiki/Main_Page Error: Class "FlaggedArticle" not found Backtrace: from C:\xampp\htdocs\w\extensions\Widgets\SmartyResourceWiki.php(34) #0 C:\xampp\htdocs\w\extensions\Widgets\vendor\smarty\smarty\libs\sysplugins\smarty_resource_custom.php(75): SmartyResourceWiki->fetch(string, NULL, NULL) #1 C:\xampp\htdocs\w\extensions\Widgets\vendor\smarty\smarty\libs\sysplugins\smarty_template_source.php(211): Smarty_Resource_Custom->getContent(Smarty_Template_Source) (...)
I don't think I have to post the entire log, but you get the idea. 😉
I can edit the Widget: page just fine. Approving and rejecting revisions also works. But when I try to transclude the widget, it crashes. The problem disappears when I turn FlaggedRevs off.
Sorry about that - this turned out to be a bug from 2012! I guess Widgets and FlaggedRevs don't get used much together. Anyway, I just checked in what I believe is a fix.
You did? That's great!
@Yaron Koren: And? Did you find the bug?
I think so...
This is really weird. I updated your extension using Composer. But apparently something went wrong. Composer only updated certain files, but not all. 😕
I then tried downloading the entire extension manually from the ExtensionDistributor. When I went there, it said "1.40 (latest stable MediaWiki)".
I was still on 1.39, so I upgraded to 1.40. As a result, my entire wiki collapsed. 1.40 doesn't appear to support Flagged Revisions at all! I posted about it here and here.
@Yaron Koren: Sorry for the confusion. I fixed the above issue.
I now have the latest stable MW version. I have the latest version of FlaggedRevs. I downloaded the latest version of Widgets (for MW 1.40) via Special:ExtensionDistributor. But it still gives me the exact same error.
@Yaron Koren: Ok, scratch that. I now downloaded the alpha version, i.e. the master version, i.e. the development version. Now it does work. Why is everything so complicated! 😩
It's not quite as complicated as you may have thought - you only had to switch to the latest version of the Widgets extension, not upgrade MediaWiki or FlaggedRevs. But I'm glad everything works now.
@Yaron Koren: Yeah I know, and I apologize for my convoluted response.
Do you know when the alpha/development/master version will become the stable version?
I'm getting the 502 Bad Gateway error when I save a page in my wiki that has the Widget template called, how do I solve this problem?
I am using the widget video given in the list of already designed widgets
but this one use an absolute url
and i want something like src= instead of URL=
because videos are locales to my wiki and not external
Could you please give me the syntax to change this
best regards
Because in my old version of mediawiki i used HTML5Video extension and now with version 1.39 of mediawiki it doesn't work
I would think that the Video widget already makes use of src internally. I'm not sure what you by mean "videos are locales to my wiki", but there's a couple of things you could do.
- You could rewrite the widget to make use of $_SERVER['SERVER_NAME' ]
- You could rewrite the widget to include a hard-coded reference to the domain.
Or before passing stuff to the widget:
- You could use prefix your relative urls with Help:Magic words: e.g.
https:{{SERVER}}/ - If a video is uploaded to the wiki, you can retrieve its url by using
filepath
Hope that helps.
hi !
i want to use in lokal wiki the Widget#Iframe.
The folder ..\extensions\Widgets\compiled_templates has full permisson to IIS_IUSRS and the .htaccess file, include this folder (source: deny from all) i rename.
the template .../index.php?title=Vorlage:Wiki:Iframe is create with
<includeonly><iframe src="<!--{$url|validate:url}-->" style="border: <!--{$border|escape:html|default:0}-->" width="<!--{$width|escape:html|default:400}-->" height="<!--{$height|escape:html|default:300}-->"></iframe></includeonly>
then i copy the example into side - but now i get the misstake:
Unable to load template 'wiki:Iframe'
did someone could help?
regards Jan
| os | Windows Server 2016 |
| mediawiki | 1.36.1 |
| php | php-7.4.20-nts-Win32-vc15-x64 |
| mysql | mysql-5.7.12-winx64 |
Please review the widget description carefully, section 'Copy to your site' www.mediawikiwidgets.org/Widget:Iframe
To resolve the issue, you need to create Widget:Iframe page like this:
.../index.php?title=Widget:Iframe
and copy the 'full source code' to the page.
I ported some functional widgets from a different wiki running MW 1.31 and Widgets v1.3.1 to mine, which is running MW 1.38 and Widgets v1.4.1. However, some of these ported widgets are not working. In particular, I see errors about mw.hook and mw.loader.using not being a function.
I tried to log them in the console as the widget loads, mw shows up as an object with all the expected properties, but mw.hook and mw.loader.using are both undefined.
A simple script to reproduce the issue is as follows:
window.RLQ.push(async () => {
console.log(mw); // this shows up as a regular object
console.log(mw.loader.using); // this shows up as undefined
console.log(mw.hook); // this shows up as undefined
});
I typed the names of all these packages in the console after the web page loaded. Everything shows up normally, implying that the widget is perhaps loaded before core mw packages are available.
I feel like I'm missing something very obvious, but I don't know much about javascript and cannot find any migration guides/tutorials that may explain this phenomenon. Everything I saw suggested that mw.hook and mw.loader.using are loaded before everything else and that I don't need to do anything special to use them. Any help is appreciated. Thank you!
Hi, I honestly don't know but you're relying on a number of ResourceLoader's core modules (mw.loader.using, etc.). As far as I know, the Widgets extension has no support for them out of the box, so I wonder how that issue was solved on the older wiki.
One hack you could try, though it really is a stab in the dark, is to edit extension.json and load the required modules as dependencies, which may or may not also include jQuery.
Another route you might consider is move your JavaScript to MediaWiki:Common.js instead, which comes with built-in support for ResourceLoader although you will probably have to rewrite some of your code (or have it rewritten).
@Cavila Thanks for the reply! I saw in another thread called "JQuery access" that upgrading from MW 1.31 to 1.34 breaks jquery, so the issues with mw.hook and mw.loader.using might have a similar cause.
I thought extension.json configures the dependencies of an extension, so it shouldn't affect the order in which js scripts are loaded?