Extension talk:Widgets

Jump to navigation Jump to search

About this board

Old messages are archived.


Cavila (talkcontribs)

After failing to get this extension to work using manual installation, I managed to do it using composer. I wondered why the former approach didn't work for me.

Previously we had to put the libs folder inside the smarty folder, but I now see, after using composer, that the contents of the libs folder are inside the smarty folder. Did something change? Should the docs for manual installation be updated?

Kghbln (talkcontribs)

Probably yes. I have not installed this extension manually in many years so I do not really know how this is done properly. I will add a note saying that the instructions may be out of date.

Reply to "Update documentation?"

Zip method Fatal error: Uncaught Error: Class 'Smarty' not found in WidgetRenderer.php:24

3
Summary by TiltedCerebellum

Again disabled. https://phabricator.wikimedia.org/T276021

Also MW is not compatible with Composer 2 yet: https://phabricator.wikimedia.org/T266417

TiltedCerebellum (talkcontribs)

Followed the directions for installing via Zip method, after activating receive:

Fatal error: Uncaught Error: Class 'Smarty' not found in /home/username/sitename.com/extensions/Widgets/WidgetRenderer.php:24

Is there a chance these instructions need to be updated/changed?

No composer access on the host this is installed on

MediaWiki 1.35.0
PHP 7.4.12 (cgi-fcgi)
MySQL 5.7.28-log
ICU 57.1
Lua 5.1.5
MarkAHershberger (talkcontribs)
TiltedCerebellum (talkcontribs)

Thanks, I tried a few different methods for smarty, and those didn't work with provided zip. Ended up doing the composer install for the friend's host account this was on and installing from git. With that we ended up with two other errors that suggest Widgets is not fully compatible with 1.35, ended up abandoning Widgets.

Topic:Vup11rltwtnsgzok

https://phabricator.wikimedia.org/T276023

https://phabricator.wikimedia.org/T276021

We weren't using it for that much, so we're just removing the stuff we did use it for until it's updated and whatever conflicts are sorted.

Since upgrading fatal error Smarty_Internal_TemplateBase

6
Summary by TiltedCerebellum

Disabled extension

TiltedCerebellum (talkcontribs)

PHP Fatal error:  Class 'Smarty_Internal_TemplateBase' not found in /site/public/extensions/Widgets/vendor/smarty/smarty/libs/Smarty.class.php

Product Version
MediaWiki 1.33.0 (62dc614)
PHP 7.2.19 (cgi-fcgi)
MySQL 5.7.28-log
ICU 52.1


Kghbln (talkcontribs)

Try to re-install according to the new instuctions. They changed in newer versions. Probably smarty was not installed properly.

TiltedCerebellum (talkcontribs)

I did that, didn't help

Kghbln (talkcontribs)

Just to make sure: You used Git and Composer?

TiltedCerebellum (talkcontribs)

Yep, this is still showing in my php error log intermittently

Kghbln (talkcontribs)

Admittedly I have no clue. I have this extension working both on a MW 1.33 and a MW 1.34 with no issues at all.

Lakelimbo (talkcontribs)

Hi.

After another exploit with the extension (December 2020), wouldn't be better to classify the extension under "Unstable extensions"? Miraheze and probably other wikifarms and some independent wikis removed the extension because of this.

Kghbln (talkcontribs)

I personally do not think so. There are more extensions with frequents exploits around. In the end this is a matter of updating what you have in due time.

MGChecker (talkcontribs)

I agree that the last two exploits were quite bad and obvious as well. However, they were fixed in no time – this extension is indeed actively maintained.

This is why I think we should warn about the fact that this very type of extension is naturally susceptible to security flaws with respect to unsanitized input etc., but still designate it as stable.

In the long run, there should probably some kind of tutorial about how to use this extension securely, as well as a security review.

MGChecker (talkcontribs)

I just want to point out, that ShoutWiki und Fandom still have these extension deployed.

Pppery (talkcontribs)

Although Miraheze undeployed the extension as a reaction to the security issues.

MGChecker (talkcontribs)

Sure, and I think this is no too far-fetched decision and understandable. But recommending an undeployment everywhere else does not really follow as a consequence thereof in my opinion.

Reply to "Stability of the extension"

Composer lock file permission denied

2
Summary by Kghbln

Check the permissions of the respective folder.

Jonathan3 (talkcontribs)

At the composer stage I get the following. Is it anything to worry about? I'm moving to a new server and haven't checked the extension works yet.

Loading composer repositories with package information
Updating dependencies
Lock file operations: 19 installs, 0 updates, 0 removals
  - Locking composer/semver (2.0.0)
  - Locking composer/spdx-licenses (1.5.4)
  - Locking mediawiki/mediawiki-codesniffer (v33.0.0)
  - Locking mediawiki/minus-x (1.1.0)
  - Locking php-parallel-lint/php-console-color (v0.3)
  - Locking php-parallel-lint/php-console-highlighter (v0.5)
  - Locking php-parallel-lint/php-parallel-lint (v1.2.0)
  - Locking psr/container (1.0.0)
  - Locking smarty/smarty (v3.1.36)
  - Locking squizlabs/php_codesniffer (3.5.8)
  - Locking symfony/console (v5.1.8)
  - Locking symfony/polyfill-ctype (v1.20.0)
  - Locking symfony/polyfill-intl-grapheme (v1.20.0)
  - Locking symfony/polyfill-intl-normalizer (v1.20.0)
  - Locking symfony/polyfill-mbstring (v1.20.0)
  - Locking symfony/polyfill-php73 (v1.20.0)
  - Locking symfony/polyfill-php80 (v1.20.0)
  - Locking symfony/service-contracts (v2.2.0)
  - Locking symfony/string (v5.1.8)


  [ErrorException]
  file_put_contents(./composer.lock): failed to open stream: Permission denied


update [--with WITH] [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--lock] [--no-install] [--no-autoloader] [--no-scripts] [--no-suggest] [--no-progress] [-w|--with-dependencies] [-W|--with-all-dependencies] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--apcu-autoloader-prefix APCU-AUTOLOADER-PREFIX] [--ignore-platform-req IGNORE-PLATFORM-REQ] [--ignore-platform-reqs] [--prefer-stable] [--prefer-lowest] [-i|--interactive] [--root-reqs] [--] [<packages>]...

Jonathan3 (talkcontribs)

Apologies: `sudo chown $USER:$USER Widgets` fixed this.

Latest releases not tagged on GitHub

3
Obyford (talkcontribs)

The latest release tagged on GitHub is 1.30 (which is the same commit the REL1_30 branch points to) from 2017. There are branches for REL1_31 through REL1_35 but none of them have tags and therefore they do not show up on the releases page.

This means if you follow the instructions for 'Installing from a .zip file' you end up downloading v1.30 which does not include an extension.json and as far as I can tell does not work with wfLoadExtension if you follow the instructions in 'Configuration':

<code>
PHP Fatal error:  Uncaught Exception: Unable to open file /home/[user]/public_html/wiki/extensions/Widgets/extension.json: filemtime(): stat failed for /home/[user]/public_html/wiki/extensions/Widgets/extension.json in /home/[user]/public_html/wiki/includes/registration/ExtensionRegistry.php:136

Stack trace:
#0 /home/[user]/public_html/wiki/includes/GlobalFunctions.php(52): ExtensionRegistry->queue('/home/[user]/pu...')
#1 /home/[user]/public_html/wiki/LocalSettings.php(145): wfLoadExtension('Widgets')
#2 /home/[user]/public_html/wiki/includes/Setup.php(124): require_once('/home/[user]/pu...')
#3 /home/[user]/public_html/wiki/includes/WebStart.php(81): require_once('/home/[user]/pu...')
#4 /home/[user]/public_html/wiki/index.php(41): require('/home/[user]/pu...')
#5 {main}
  thrown in /home/[user]/public_html/wiki/includes/registration/ExtensionRegistry.php on line 136
</code>
Obyford (talkcontribs)

It looks like there are more issues if you try to follow the 'Install from a .zip file' instructions – the instructions say to copy the smarty libs into the smarty folder, but I can't see anything that actually takes care of including that class?

<code>
/wiki/index.php?title=Albert%27s_Lyrebird&action=submit   Error from line 24 of /home/[user]/public_html/wiki/extensions/Widgets/WidgetRenderer.php: Class 'Smarty' not found
</code>
Kghbln (talkcontribs)

Indeed this extension is no longer being tagged. Also installing from zip is no longer the preferred way. Anyhow I updated to link to point to the branches. There you can pick the branch matching your version of MediaWiki and hopefully all of this works. Hope this helps.

Reply to "Latest releases not tagged on GitHub"

Is there a way to allow anyone to edit /doc subpages of widgets?

4
Summary by Kghbln

Also tracked with task T268142.

JsfasdF252 (talkcontribs)

All pages in the Widget namespace are protected by default. That means that only admins can edit widgets, but almost nobody can edit the documentation. Even putting documentation into dedicated subpages doesn't work. I would suggest improving the extension so /doc, /sandbox, and /testcases subpages are unprotected by default.

MGChecker (talkcontribs)

I fear here is no easy and secure way to do this. Have you considered moving these pages into another Namespace, like "Widget documentation"? This would prevent problems like this.


If this extension would implement its own content model to realize widgets, it might be feasible. But this would imply a major architecture change.

Kghbln (talkcontribs)

I personally do not use widgets directly on a page. What I do is create an accompanying template of the same name which uses the same parameters as the widget. Another advantage doing so: You can see the transclusions of the template or even add a hidden category to track where the widget is used on a wiki. Moreover you can add all subpages as you like to the template namespace. Thus you issue will be solved.

Kghbln (talkcontribs)

The Html5media template matching the Html5media widget could e.g. look like this:

<includeonly>{{#widget:Html5media
 |url={{#if: {{{url|}}}
  |{{{url|}}}
  |{{filepath: {{{name|}}} }}
 }}
 |width={{{width|425}}}
 |height={{{height|355}}}
}}</includeonly>

This is acutally even extending the widget, i.e. for locally hosted files you only need to add the file name instead of the URL.

Reply to "Is there a way to allow anyone to edit /doc subpages of widgets?"
Summary by MarkAHershberger

Trial and error that could have been avoided with better documentation.

199.104.151.131 (talkcontribs)

I have installed this extension on MediaWiki 1.33.

I followed the instructions on Extension:Widgets, created a page for YouTube and Google Calendar widgets under namespace Widget. Are these just supposed to be empty pages? That's what I made.


I tried making a Google Calender and YouTube widget. I get no errors, but the widgets are not displayed. I can see in extensions/Widgets/compiled_templates, that when I made my first Google Calendar, then YouTube templates new php files are created in there.


How do I debug this?

199.104.151.131 (talkcontribs)

Nevermind I eventually figured it out with more effort than should take. The documentation of this extension needs to be clarified badly.

1) In the installation section, there is no mention of the download available in the sidebar of the extension page! Special:ExtensionDistributor/Widgets. This is worth mentioning. The installation instructions for this method should note that once it is copied into the extensions directory, it is ready to go and nothing else needs be done except to put the proper line into LocalSettings.php to ensure it is available to the wiki. Maybe you still need to change the directory permissions of compiled_templates. I did that anyway before I did anything else.


2) The Usage section says: "To add a widget to your MediaWiki installation, just create a page in the Widget: namespace and then use the {{#widget:...}} parser function to include it in the pages of the wiki." There is more to it that that! These instructions omit the fact that you must go to mediawikiwidgets.org and copy code into that new page you create on your wiki. For example to enable Google Calendar, you must copy the contents of the code from the Google Calendar description page on mediawidgets.org into your new page under Widget:Google_Calendar. (I can't post the link because any links on this wiki are automatically marked as spam!!)


3) Finally there is a very important part in "Refreshing a widget page" . You must indeed purge your page to see it otherwise it will continue to fail to render on your wiki under you do this.

Hard time installing "500 internal server error"

2
24.45.134.47 (talkcontribs)

So I followed the directions...

downloaded widgets, unpacked it into a folder called "Widgets" under extensions

downloaded smarty, unpacked it into the same folder

There was already a smarty folder in widgets, I moved libs into the smarty folder.

I set compiled_templates to 777

I added the text to localsettings.php

I get an error. I remove the text from localsettings and site is back and running.

MarkAHershberger (talkcontribs)

That error indicates something is probably in your error log. Did you check there to see what it says?

Reply to "Hard time installing "500 internal server error""
188.109.172.72 (talkcontribs)

So this article links to site which looks like it was designed by an eight year old, and says that due to "privacy concerns", it requires people to log in (and thus provide an email adress, making the point about "privacy concerns" laughable) even if they just want to look at the contents, making this whole extension utterly unusable if you dont want to give your private data to some guy who designed a website that honestly looks like a phishing site.

Furthermore, the website says that it will ask for consent _after_ one has logged in, which is of course utterly ridiculous.

So now my question is: Why does this Wiki link to such a site?

Kghbln (talkcontribs)

I guess you should think about what you have written and come back here actually displaying character of somebody who is older than eight years. Thanks.

Kghbln (talkcontribs)

No answer. This is what I expected. No grit at all, just vomit.

Acnetj (talkcontribs)

I do see his point why should that site require a log in to see the examples.

Kghbln (talkcontribs)

You are probably not from Europe. The examples send out personal data to all kinds of services in some cases to unknown directions. I need your consent before this happens.

Acnetj (talkcontribs)

There are extensions that can take care of this requirement without having to log-in in order to give consent.

Extension:CookieWarning

Kghbln (talkcontribs)

No this is not enough. This is about cookies. I am talking about all sorts of data being collected and sent of to wherever.

Lady G2016 (talkcontribs)

Instead of blocking the site and forcing a login to accept your Terms of Use, may I suggest a "Click to accept" approach? It's known as a Clickwrap agreement. Many sites do this, no login is required. As noted in the Wikipedia article, a clickwrap agreement will meet GDPR requirements.

I accept the agreement and can proceed to read the site. If I do not accept the agreement, I am blocked from reading the site.

A google search as "clickwrap examples" will provide ideas how to implement the approach.

Kghbln (talkcontribs)

Thank you for the suggestion. Is there an extension around which performs this task?

Reply to "mediawikiwidgets.org"