Differences

This shows you the differences between two versions of the page.

--- plugin:plugin [2018-05-06 20:33] – Klap-in
+++ plugin:plugin [2023-02-28 21:26] (current) – Aleksandr
@@ Line 14: / Line 14: @@
 screenshot_img : :pluginmanager.png
 ----
 ===== Important Notice =====
-:!: The Plugin Manager plugin was bundled with Dokuwiki up to version Binky (2013-12-08). Since version Ponder Stibbons (2014-05-05) the Plugin Manager is superseded by the [[plugin:extension|Extension Manager]].
+The Plugin Manager plugin was bundled with Dokuwiki up to version Binky (2013-12-08).
+:!: Since version Ponder Stibbons (2014-05-05) the Plugin Manager is superseded by the [[plugin:extension|Extension Manager]].
 ===== Description =====
 The Plugin Manager plugin allows [[config:superusers]] to administrate installed plugins and install new ones.
 ===== Usage =====
@@ Line 90: / Line 95: @@
-All the download-links to github are automatically redirected to ssl-connections, no opt-out planned ((See here: http://support.github.com/discussions/repos/4951-downloads-without-redirect-to-https)).
+All the download-links to github are automatically redirected to ssl-connections, no opt-out planned ((See here: https://support.github.com/discussions/repos/4951-downloads-without-redirect-to-https)).
 Problem is, as of now SSL transports are disabled on XAMPP and UniServer (WAMPs) and all cheap webhosters I tried so far (even those very few, that allow sockets at all).
@@ Line 107: / Line 112: @@
  --- [[user>bjoernX|bjoernX]] //2011/04/25 09:32//
-> This is a known problem, see http://support.github.com/discussions/site/2232-allow-downloads-via-http-non-ssl. Yes, you're unfortunately right: No easy fix there. --- [[user>ach|Anika Henke]] //2011/04/25 10:47//
+> This is a known problem, see https://support.github.com/discussions/site/2232-allow-downloads-via-http-non-ssl. Yes, you're unfortunately right: No easy fix there. --- [[user>ach|Anika Henke]] //2011/04/25 10:47//
 >> Thanks, Anika. Strange discussion there... it almost seems, they don't get the point. Claiming security at github against plain http as an //option// for package downloads sound ridiculous to me. I was wondering -- maybe some kind of proxy in-the-middle thing might work, but I'm not sure, if it's worth the effort.   --- [[user>bjoernX|bjoernX]] //2011/04/26 13:42//
@@ Line 115: / Line 120: @@
 ----
-A solution that often works when your shared webhosting doesn't allow direct access to //php.ini// is to use a custom //php.ini// within your user directory. [[http://websistent.com/using-custom-php-ini-files-on-shared-hosting/|See a guide on how to do this.]]  --- [[user>SFITCS|SFITCS]] //2016-11-06 08:22//
+A solution that often works when your shared webhosting doesn't allow direct access to //php.ini// is to use a custom //php.ini// within your user directory. [[https://websistent.com/using-custom-php-ini-files-on-shared-hosting/|See a guide on how to do this.]]  --- [[user>SFITCS|SFITCS]] //2016-11-06 08:22//
 ----
@@ Line 123: / Line 128: @@
 Update via the plugin manager fails.
-   Downloading archive from https://github.com/splitbrain/dokuwiki/tarball/master?.tgz...
+   Downloading archive from https://github.com/dokuwiki/dokuwiki/tarball/master?.tgz...
 Issue was eventually diagnosed as a /dev/urandom with incorrect permissions. Changing it to 777 was the magic bullet.