I'm trying to automate Wikimedia installation using Ansible and the Wikimedia command-line install script.
I noticed the current version includes script parameters for installing extensions. From the script help command:
$ php maintenance/install.php --help
CLI-based MediaWiki installation and configuration.
Default options are indicated in parentheses.
Usage: php install.php [--conf|--confpath|--dbgroupdefault|--dbname|--dbpass|--dbpassfile|--dbpath|--dbport|--dbprefix|-
-dbschema|--dbserver|--dbtype|--dbuser|--env-checks|--extensions|--globals|--help|--installdbpass|--installdbuser|--lang
|--memory-limit|--mwdebug|--pass|--passfile|--profiler|--quiet|--scriptpath|--server|--skins|--wiki|--with-extensions] [
name] <admin>
...
Script specific parameters:
--extensions: Comma-separated list of extensions to install
--with-extensions: Detect and include extensions
However, I am unable to find any other information on how best to use these parameters. Neither the Wikimedia manual pages on the install.php script or Extensions documents them:
https://www.mediawiki.org/wiki/Manual:Install.php
https://www.mediawiki.org/wiki/Manual:Extensions
Can someone point me to more details documentation on these parameters or provide an example of how to use them?
I am planning to do some trial and error and will answer this question myself if I figure out how they work before anyone else answers. But I know extension installation can get complicated and usually involves making config file updates so I hope I could find some existing documentation to guide me.
Short Answer
These extension parameters simply add a line to the LocalSettings.php file, if the named extension is found in the extensions directory, to load the extension at runtime.
Long Answer
I played with this a little. I tested the --with-extensions which, per the help docs, will detect and include extensions. What this appears to mean is that it will scan the extensions directory and install any extensions it find there.
I ran the following command:
php maintenance/install.php --with-extensions --dbserver="localhost" --dbname=foo --dbuser=foo --dbpass=foo --server="https://wiki.foo.localhost" --script path=/mediawiki -en --pass=foo "My Wiki Name" "Admin"
It produced the following block in my LocalSettings.php config file listing the default packages included with the current version of the Mediawiki core:
# Enabled extensions. Most of the extensions are enabled by adding
# wfLoadExtensions('ExtensionName');
# to LocalSettings.php. Check specific extension documentation for more details.
# The following extensions were automatically enabled:
wfLoadExtension( 'CategoryTree' );
wfLoadExtension( 'Cite' );
wfLoadExtension( 'CiteThisPage' );
wfLoadExtension( 'CodeEditor' );
wfLoadExtension( 'ConfirmEdit' );
wfLoadExtension( 'Gadgets' );
wfLoadExtension( 'ImageMap' );
wfLoadExtension( 'InputBox' );
wfLoadExtension( 'Interwiki' );
wfLoadExtension( 'LocalisationUpdate' );
wfLoadExtension( 'MultimediaViewer' );
wfLoadExtension( 'Nuke' );
wfLoadExtension( 'OATHAuth' );
wfLoadExtension( 'ParserFunctions' );
wfLoadExtension( 'PdfHandler' );
wfLoadExtension( 'Poem' );
wfLoadExtension( 'Renameuser' );
wfLoadExtension( 'ReplaceText' );
wfLoadExtension( 'SpamBlacklist' );
wfLoadExtension( 'SyntaxHighlight_GeSHi' );
wfLoadExtension( 'TitleBlacklist' );
wfLoadExtension( 'WikiEditor' );
The complexity of this parameter, probably wisely, goes no further than that.
I tried running this command to see if the --extensions=GoogleLogin parameter would auto-magically install the GoogleLogin extension. It did not. Rather it reported this error:
Could not find the registration file for the extension "GoogleLogin"
So if you're looking for a more full-featured Composer-like extension package-manager, this is not it.
When I downloaded the GoogleLogin extension and placed it in the extensions directory and ran the --with-extensions parameter and it did include it in the config file extensions block.
Without explicitly testing it, I concluded the --extensions parameters operates the same way as --with-extensions except that it will rewrite to the LocalSettings.php config file only those extensions explicitly specified and found in the extensions directory.
Related
I deleted a WordPress plugin to install an older version of that plugin but the new version continues to show on the front end.
Steps I have taken:
I deleted the plugin folder.
Searched the database for any tables left behind by the plugin. No tables.
Searched the plugins scripts to see how it connects to database. I searched for the terms $wpdb, set_option() and update_option(). I only found update_option() in this plugins scripts.
I found the following in different locations in this plugins folder:
update_option( $option_key, $savedOptions );
update_option( $this->tabs[ $tab_id ][ 'option_key' ], array() );
update_option( $option_key, $option_data );
update_option( 'xoo_'.$this->slug.'_theme_templates_data', $tempData );
update_option( 'xoo-ml-before-2', 'yes' );
update_option( $version_option, XOO_WSC_VERSION);
And this is where I am stuck... Does any of the above code store info in the database that would prevent me from getting the old version of the plugin back?
My research has me looking in the direction of _options table but I am not sure what to do their or if that is where I need to be...
There is a project split into several repositories cloned into separated folders. There is a library which is not referenced in package.json (and mustn't be) of other repositories as it is added via a build script.
How can I override WebStorm so that it does not display "Module is not installed" error for every import from that?
N.b., I need the library where it is, not in node_modules, so adding it to package.json is not a solution.
For me, this warning was displaying for all local imports. I resolved it by adding the path to the WebPack config file.
Preferences -> Languages & Frameworks -> JavaScript -> WebPack
Other than File -> Invalidate Caches / Restart, which will take some time for WS to reindex, you can use this workaround
You can disable the "Missing module dependency" inspection in the whole project either in Preferences | Editor | Inspections or by hitting Alt-Enter on the highlighted error, then arrow right - Disable inspection.
You can also create a new Scope that excludes that folder in Preferences | Appearance and Behavior | Scopes and then set the inspection's scope to it.
I solved this problem a bit differently. I added file webpack.alias-config.js in my main folder of project:
const path = require('path')
module.exports = {
resolve: {
alias: {
'#': path.join(__dirname, 'src'),
},
},
}
Next I added path to this file (webpack.alias-config.js) in: Settings -> Languages & Frameworks -> JavaScript -> Webpack:
And now I can use this alias e.g:
import MyFile from '#/components/MyFile'
In my case everything was set up correctly, but I had node_modules as exception in Settings: Editor -> File Types -> Ignore files and folders. The problem was solved after I removed it from there and waited for indexing.
For Laravel Mix users, Jetbrains products dont support the Laravel Mix config file.
Use one of these workarounds:
https://youtrack.jetbrains.com/issue/WEB-42186 (I prefer this one, because you dont need to create or edit the existing files)
Path aliases for imports in WebStorm
I did some research on MediaWiki hooks.
To the best of my knowledge, the only hook for adding/updating database tables is https://www.mediawiki.org/wiki/Manual:Hooks/LoadExtensionSchemaUpdates.
However, I need a hook that fires on installing a new extension. How do I achieve that? I'd like to execute a CREATE TABLE statement only once - when the extension is installed. Installing an extension doesn't require a MediaWiki update, which is why the above hook does not suit my needs.
EDIT
To clarify: I'm developing an extension that requires access to a custom table in the database. That's why I need to execute the CREATE TABLE statement whenever this extension is installed.
First: As you have noticed, there is no such hook. You will need to do the check for installed extensions by a cron job (if it's your server), or on, say, each 100th request to the wiki, using the job queue (if you are doing this in an extension).
From there, you have a few options, depending on if you need to catch every single extension, or just most of them:
Check for registered extensions, with something like: $registry = ExtensionRegistry::getInstance();$extensions = $registry->loaded();This will work extensions using the new style. For older versions, check the global variable $wgExtensionCredits for registered extensions. Note that nothing prevents an extensions from running without registering. In fact, there are a lot of extensions like that.
Parse LocalSettings.php, and check for old and new style extension loading with a regex. Very dirty, but it's actually the way e.g. the maintainance script getConfiguration.php does it. You need to check for lines like this:wfLoadExtension( 'FooBar' );and this:wfLoadExtensions( ['Foo', 'Bar'] );and this:require_once "$IP/extensions/Foo/Bar.php"; Note however that it is possible to use other directories for extensions, and that modern skins in fact behave like extensions too.
If you need to track a certain family of extensions, and you can make sure they all use Composer, the parse $IP/composer.json for installed extensions.
I did some more research (https://www.mediawiki.org/wiki/Manual:Update.php#Details) and found out that the LoadExtensionSchemaUpdates hook is exactly what I am looking for.
# Schema updates for update.php
$wgHooks['LoadExtensionSchemaUpdates'][] = 'fnMyHook';
function fnMyHook( DatabaseUpdater $updater ) {
$updater->addExtensionTable( 'tablename',
__DIR__ . '/table.sql' );
return true;
}
When running $ php update.php for the first time after installing the extension, the script executes the CREATE TABLE statement. Then, for consecutive executions, the update script just notes that the table already exists.
I have the following reference in some of my PHP files:
require_once "../folder/subfolderone/referencedFile.php";
When I move the above file to a different folder at
../folder/subfoldertwo/referencedFile.php
and check the search for references option when moving the file, the require_once references in my other files are not changed.
How do I get PHPStorm to recognize the file move?
As far as I'm aware it is still not supported.
https://youtrack.jetbrains.com/issue/WI-4439 -- star/vote/comment to get notified on progress.
P.S.
If this code is yours and it is new (not some old project) -- consider using autoloading functionality for your classes (be it writing your own simple autoloader or using composer autoloader for that) -- especially if it's namespaced code.
I am trying to populate a pdf report with data from my mysql database. It works fine on my local machine but when I upload it to www.000webhost.com, the pdf document is not generated.
I know the document writes a temp file to my folder every time I click print report.Can anyone tell me why it doesn't work on the hosting provider and how I can fix this issue. I am under the impression that it is a security issue.
Do I have to write a temp file. Why couldn't I have used the $fdf variable to populate the report instead of the temporary file?
$fdf_fn= tempnam( '.', 'fdf' );
$fp= fopen( $fdf_fn, 'w' );
if( $fp ) {
fwrite( $fp, $fdf );
fclose( $fp );
//attachment for view
header( 'Content-type: application/pdf' );
header( 'Content-disposition: inline; filename=TEST.pdf');
passthru( "pdftk ./../../reports/TEST.pdf fill_form ". $fdf_fn.' output - flatten' );
unlink( $fdf_fn ); // delete temp file
Can anyone tell me why it doesn't work on the hosting provider and how
I can fix this issue. I am under the impression that it is a security
issue.
My guess is you simply don't have write permission in the required directory.
You create your temporary file in the current working directory (.). Depending on your hosting provider and the HTTP server configuration, the current working directory is not necessary what you think nor writable. Especially since your program will probably run with the www or nobody identity.
I assume you have to create and then adjust the permissions on your "temporary" directory -- or use a "world writable" location such as /tmp.
Finally, you have a relative path that move "upward" in your program: ./../../reports/TEST.pdf fill_form There is little chances for this to be valid on your hosting...