Project:Support desk

Jump to navigation Jump to search

About this board

Welcome to MediaWiki.org's Support desk, where you can ask MediaWiki questions!

There are also other places where to ask :

Before you post

Post a new question

  1. To help us answer your questions, please always indicate which versions you are using (reported by your wiki's Special:Version page):
    • MediaWiki
    • PHP
    • Database
  2. Please include the URL of your wiki unless you absolutely can't. It's often a lot easier for us to identify the source of the problem if we can look for ourselves.
  3. To start a new thread, click "Start a new topic".
Previous page history was archived for backup purposes at Project:Support_desk/old on 2015-07-30.
Other languages: English  العربية čeština Esperanto français 日本語 中文

Installing Extension:Echo has messed up something

25
Dodger67 (talkcontribs)

I followed the instructions for installing Extension:Echo to the letter but after the last step - running the "Update script" - I get this long detailed error message that I don't understand:

Original exception: [ae2d7c99] /wiki/index.php?title=Main_Page DBQueryError from line 1119 of /home/krdspmen/public_html/wiki/includes/db/Database.php: A database error has occurred. Did you forget to run maintenance/update.php after upgrading? See: https://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script Query: SELECT etp_user,etp_page,etp_event FROM `mwsz_echo_target_page` WHERE etp_user = '2' AND etp_page = '1' Function: EchoTargetPageMapper::fetchByUserPageId Error: 1146 Table 'krdspmen_mw269.mwsz_echo_target_page' doesn't exist (localhost)

Backtrace:

  1. 0 /home/krdspmen/public_html/wiki/includes/db/Database.php(1076): DatabaseBase->reportQueryError(string, integer, string, string, boolean)
  2. 1 /home/krdspmen/public_html/wiki/includes/db/Database.php(1600): DatabaseBase->query(string, string)
  3. 2 /home/krdspmen/public_html/wiki/extensions/Echo/includes/mapper/TargetPageMapper.php(38): DatabaseBase->select(array, array, array, string)
  4. 3 /home/krdspmen/public_html/wiki/extensions/Echo/Hooks.php(643): EchoTargetPageMapper->fetchByUserPageId(User, integer)
  5. 4 [internal function]: EchoHooks::onPersonalUrls(array, Title, SkinVector)
  6. 5 /home/krdspmen/public_html/wiki/includes/Hooks.php(204): call_user_func_array(string, array)
  7. 6 /home/krdspmen/public_html/wiki/includes/skins/SkinTemplate.php(688): Hooks::run(string, array)
  8. 7 /home/krdspmen/public_html/wiki/includes/skins/SkinTemplate.php(455): SkinTemplate->buildPersonalUrls()
  9. 8 /home/krdspmen/public_html/wiki/includes/skins/SkinTemplate.php(240): SkinTemplate->prepareQuickTemplate(OutputPage)
  10. 9 /home/krdspmen/public_html/wiki/includes/OutputPage.php(2314): SkinTemplate->outputPage()
  11. 10 /home/krdspmen/public_html/wiki/includes/MediaWiki.php(690): OutputPage->output()
  12. 11 /home/krdspmen/public_html/wiki/includes/MediaWiki.php(476): MediaWiki->main()
  13. 12 /home/krdspmen/public_html/wiki/index.php(41): MediaWiki->run()
  14. 13 {main}

Exception caught inside exception handler: [8da5ecb9] /wiki/index.php?title=Main_Page DBQueryError from line 1119 of /home/krdspmen/public_html/wiki/includes/db/Database.php: A database error has occurred. Did you forget to run maintenance/update.php after upgrading? See: https://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script Query: SELECT etp_user,etp_page,etp_event FROM `mwsz_echo_target_page` WHERE etp_user = '2' AND etp_page = '1' Function: EchoTargetPageMapper::fetchByUserPageId Error: 1146 Table 'krdspmen_mw269.mwsz_echo_target_page' doesn't exist (localhost)

Backtrace:

  1. 0 /home/krdspmen/public_html/wiki/includes/db/Database.php(1076): DatabaseBase->reportQueryError(string, integer, string, string, boolean)
  2. 1 /home/krdspmen/public_html/wiki/includes/db/Database.php(1600): DatabaseBase->query(string, string)
  3. 2 /home/krdspmen/public_html/wiki/extensions/Echo/includes/mapper/TargetPageMapper.php(38): DatabaseBase->select(array, array, array, string)
  4. 3 /home/krdspmen/public_html/wiki/extensions/Echo/Hooks.php(643): EchoTargetPageMapper->fetchByUserPageId(User, integer)
  5. 4 [internal function]: EchoHooks::onPersonalUrls(array, Title, SkinVector)
  6. 5 /home/krdspmen/public_html/wiki/includes/Hooks.php(204): call_user_func_array(string, array)
  7. 6 /home/krdspmen/public_html/wiki/includes/skins/SkinTemplate.php(688): Hooks::run(string, array)
  8. 7 /home/krdspmen/public_html/wiki/includes/skins/SkinTemplate.php(455): SkinTemplate->buildPersonalUrls()
  9. 8 /home/krdspmen/public_html/wiki/includes/skins/SkinTemplate.php(240): SkinTemplate->prepareQuickTemplate(OutputPage)
  10. 9 /home/krdspmen/public_html/wiki/includes/OutputPage.php(2314): SkinTemplate->outputPage()
  11. 10 /home/krdspmen/public_html/wiki/includes/exception/MWException.php(204): OutputPage->output()
  12. 11 /home/krdspmen/public_html/wiki/includes/exception/MWException.php(244): MWException->reportHTML()
  13. 12 /home/krdspmen/public_html/wiki/includes/exception/MWExceptionHandler.php(69): MWException->report()
  14. 13 /home/krdspmen/public_html/wiki/includes/exception/MWExceptionHandler.php(180): MWExceptionHandler::report(DBQueryError)
  15. 14 /home/krdspmen/public_html/wiki/includes/MediaWiki.php(485): MWExceptionHandler::handleException(DBQueryError)
  16. 15 /home/krdspmen/public_html/wiki/index.php(41): MediaWiki->run()
  17. 16 {main}

I'm a total newbie at PHP so please assume I know nothing - I need "paint by numbers" help.

Dodger67 (talkcontribs)

Someone, please help.

The prospective users are getting impatient.

NH35 (talkcontribs)

Chane name of the echo tables. For example `echo_event` TO "wikiecho_event"

"wiki" is my prefix.

88.130.123.156 (talkcontribs)

You should call update.php, but you obviously are calling /wiki/index.php?title=Main_Page, meaning your main page.

Correct would be to run update.php from the shell, just like you are doing when you do a MediaWiki update:

cd wiki/maintenance
php update.php

The update script should then add the necessary tables to the database.

Ciencia Al Poder (talkcontribs)
Dodger67 (talkcontribs)

I've run the update multiple times - the exact same error occurs - in fact I think it is actually the update that causes the error.

As the wiki contains no user generated content yet I could simply re-install everything from scratch. But I have no assurance that the current version of Extension:Echo is actually compatible with 1.26.0. Everything was working correctly until I added Echo.

The wiki I'm building really does need a functional way to "ping" users - is Echo the only way to do it? Most of my users are total newbies to a wiki and would have a hard time keeping up with watchlists, at least until they become more proficient.

Dodger67 (talkcontribs)

Pinging this topic - it seems to be falling off the back

88.130.121.191 (talkcontribs)

You are right, the error is caused by the update of extension Echo:

A database error has occurred. 
Query: SELECT etp_user,etp_page,etp_event FROM `mwsz_echo_target_page` WHERE etp_user = '2' AND etp_page = '1' Function: EchoTargetPageMapper::fetchByUserPageId
Error: 1146 Table 'krdspmen_mw269.mwsz_echo_target_page' doesn't exist (localhost)

The update obviously did not add the table mwsz_echo_target_page. I suspect that not only this one table has not been added, but that basically none of the database changes of extension Echo have been done.

Dodger67 (talkcontribs)

Thanks for the confirmation. Does this mean Echo is simply not compatible with 1.26.0 or is there a way to make it work?

88.130.121.191 (talkcontribs)

I think there definitely will be a way to make it work. However, I do not know, how exactly the extension is supposed to add its SQL to the update.php script, so that this script recognizes it.

It looks to me like the file Extension/echo.sql contains the structure of the tables, which the extension needs. So it might be a workaround to manually run the commands from that file inside your wiki database. Note that I have not tested this.

This post was hidden by Ciencia Al Poder (history)
163.116.6.92 (talkcontribs)

I have the same problem after installation of Echo Extension, version stable 1.26.

NH35 (talkcontribs)

Also the same problem...

87.123.18.176 (talkcontribs)

Have you tried the hints by 88.130.121.191?

You should manually add the tables/columns of extension Echo to the database. In order to do that, take the SQL commands from the file Extension/echo.sql, prefix the table names with your table prefix (if you are using one) and run them in your wiki database to add the missing tables/columns.

Afterwards, you should no longer get the error "1146 Table 'echo_target_page' doesn't exist".

AhmadF.Cheema (talkcontribs)

Limited Solution:

Used the method documented here: Manual:Hooks/LoadExtensionSchemaUpdates, for adding "a new table".

Modified the following example:

# Schema updates for update.php
$wgHooks['LoadExtensionSchemaUpdates'][] = 'fnMyHook';
function fnMyHook( DatabaseUpdater $updater ) {
	$updater->addExtensionTable( 'tablename',
		__DIR__ . '/table.sql' );
	return true;
}

Changed:

  • "tablename" - "echo_target_page" (the missing table from the error)
  • "table.sql" - "echo.sql"

Result:

# Schema updates for update.php
$wgHooks['LoadExtensionSchemaUpdates'][] = 'fnMyHook';
function fnMyHook( DatabaseUpdater $updater ) {
$updater->addExtensionTable( 'echo_target_page',
__DIR__ . '/echo.sql' );
return true;
}

Added these lines to the end of LocalSettings.php.

Was unsure whether "__DIR__" stood for the LocalSettings.php directiry or the "maintenance/update.php" directory, so I copied "echo.sql" file from the extension directory, into both these directories. Not sure which one did the trick.

After this I updated the MediaWiki installation, for which I used the "Web browser" method (because I don't have SSH access on my hosting server). This gave the following results in the "Upgrade existing installation" browser MediaWiki interface.

...spoofuser table already exists.
Creating echo_target_page table ...done.
...site_stats is populated...done.
Purging caches...done.

The WikiSdid not break like before after this and the Echo icons in the user toolbar also became visible. So, I imagine this method worked.

Testing:

On testing the extension, by creating a test account, I was unable to see notifications for watch pages and some other edits too. The only time the notifications worked was, when the user talk page was edited.

It appears that at this moment most of the features of this extension are not working, using this method.

Maybe, the other extension database tables are also not being automatically created.

Update: Just checked the other three tables from echo.sql using the same method, they were apparently automatically created like they should have been.

AhmadF.Cheema (talkcontribs)

Update:

Apparently, I made a mistake. While I was testing, I overwrote the master release of the extension onto the stable release (which I was testing before). I deleted the extension folder "Echo" completely and re-uploaded the stable release.

Notifications appear to be working now, aside from the "Mention" i.e. "Notify me when someone links to my user page" but maybe I'm testing this one wrong.

Steveengelhardt (talkcontribs)

Okay.. so this thread is like a year old and I'm getting this error now. Has this not been resolved yet? I'm following the instructions to run the update through the browser. Something i can handle. But adding adding the code in localsettings is breaking my site because the update seems like it takes you through this process, but obviously is not updating the files. I don't understand these instructions on how to update it the other way or adding tables manually and what have you. I have tried installing a couple other extensions that require this third step of running this update script and i get the same effect. My hosting is thru Siteground if maybe that has something to do with it But i feel like i'm just missing something somehow. I follow the directions : Navigate your webbrowser to /mw-config/. For example, if your wiki is at http://example.org/w/index.php, then navigate to http://example.org/w/mw-config/. I feed it the upgrade key and run thru everything. Seems like it worked visually, but has not actually updated any files aparently.

I don't understand how to run the update from the command line. Can i even get to a command line if i have hosting on siteground? I've never used it.

I'm also trying to make my wiki multilingual and running into the same wall as it requires this update step. I'm having no problem installing extensions that just require (1) to ftp the files up and (2) to add a line to the localsettings file. But all the ones that require this 3rd step of running the update crash my site

S3r3nd1 (talkcontribs)
AhmadF.Cheema (talkcontribs)

For running the update.php script, take a look at this: https://www.siteground.com/tutorials/ssh/

See if you can understand the tutorials. Additionally, you can probably ask customer support at Siteground for help with SSH too.

Steveengelhardt (talkcontribs)

After some fumbling around, I Figured out how to use putty and then actually remembered how to move directories and shit on the terminal to get to the maintenance folder to run the update script :) Happy day! Thanks. They should remove the one about updating it thru the browser, Doesn't fkn work. Thanks again! Now to figure out this node.js bit to get the visual editor... http://FlatEarthWiki.com

Bruceillest (talkcontribs)

Im running Windows server 2012R2

Product Version
MediaWiki 1.32.0
PHP 7.2.7 (cgi-fcgi)
MySQL 8.0.15
ICU 61.1

So I'm not sure why this worked but it did. I cleared out my wincache using the following script I created awhile back ago from someone else recommended for a different issue on a different extension.

<?php

wincache_ucache_set('green', 1);

wincache_ucache_set('red', 2);

wincache_ucache_set('orange', 4);

wincache_ucache_set('blue', 8);

wincache_ucache_set('cyan', 16);

$array1 = array('green', 'red', 'orange', 'blue', 'cyan');

var_dump(wincache_ucache_get($array1));

var_dump(wincache_ucache_clear());

var_dump(wincache_ucache_get($array1));

?>

I named the file wincache_ucache_clear.php and saved it to my site folder then I opened command prompt as admin and ran cd C:\inetpub\wwwroot\"YourWIKISite" then php wincache_ucache_clear.php I then ran php update.php from the maintenance directory and viola. In the stream I was able to see that it added all echo tables. Hope this helps.

AhmadF.Cheema (talkcontribs)

Did you run update.php before running wincache_ucache_clear.php? Far as I know, the issue of tables not getting automatically created was fixed and users should no longer have to go through any such hacks.

Steveengelhardt (talkcontribs)

It's still a problem. I just ran into it again very recently. It only exists when you run update.php thru the web. I didn't have access to the command line this time so i found Importing the echo.sql to database with phpMyAdmin and then adding my prefixes to the tables worked. ~ParamotorWiki.com

Bruceillest (talkcontribs)

Yes I ran update.php before running wincache_ucache_clear.php and I got the following

[fatal] [7348d6842ad5793ac217096e] update.php   PHP Fatal Error from line 5 of C:\inetpub\wwwroot\CAS\extensions\Flow\includes\Container.php: Class 'Pimple\Container' not found

After clearing cache it worked just fine.

Falcopragati (talkcontribs)

I am having the same error ,please assist me.

and please tell guide me how & where to run 'update.php' ..?

I am a total newbie at this..

This is the error-->

) Fatal error: Class 'Pimple\Container' not found in C:\wamp64\www\wiki\extensions\Flow\includes\Container.php on line 5

Reply to "Installing Extension:Echo has messed up something"

The lua binary lua is not executable

5
Summary by AhmadF.Cheema

Needed to change permissions for the lua file.

Bachounda (talkcontribs)

hello

i have a fatal exception

[a201ec8a] /index.php?title=%D9%88%D8%AD%D8%AF%D8%A9:Bananas&action=submit Exception from line 158 of /htdocs/public/www/extensions/Scribunto/engines/LuaStandalone/LuaStandaloneEngine.php: The lua binary (/htdocs/public/www/extensions/Scribunto/engines/LuaStandalone/binaries/lua5_1_5_linux_32_generic/lua) is not executable.

Backtrace:

#0 /htdocs/public/www/extensions/Scribunto/engines/LuaStandalone/LuaStandaloneEngine.php(105): Scribunto_LuaStandaloneInterpreter->__construct(Scribunto_LuaStandaloneEngine, array)

#1 /htdocs/public/www/extensions/Scribunto/engines/LuaCommon/LuaCommon.php(72): Scribunto_LuaStandaloneEngine->newInterpreter()

#2 /htdocs/public/www/extensions/Scribunto/engines/LuaStandalone/LuaStandaloneEngine.php(8): Scribunto_LuaEngine->load()

#3 /htdocs/public/www/extensions/Scribunto/engines/LuaCommon/LuaCommon.php(172): Scribunto_LuaStandaloneEngine->load()

#4 /htdocs/public/www/extensions/Scribunto/engines/LuaCommon/LuaCommon.php(655): Scribunto_LuaEngine->getInterpreter()

#5 /htdocs/public/www/extensions/Scribunto/engines/LuaCommon/LuaCommon.php(628): Scribunto_LuaModule->getInitChunk()

#6 /htdocs/public/www/extensions/Scribunto/common/Base.php(157): Scribunto_LuaModule->validate()

#7 /htdocs/public/www/extensions/Scribunto/common/Hooks.php(313): ScribuntoEngineBase->validate(string, string)

#8 [internal function]: ScribuntoHooks::validateScript(EditPage, string, string, string)

#9 /htdocs/public/www/includes/Hooks.php(206): call_user_func_array(string, array)

#10 /htdocs/public/www/includes/GlobalFunctions.php(4013): Hooks::run(string, array, NULL)

#11 /htdocs/public/www/includes/content/ContentHandler.php(1120): wfRunHooks(string, array)

#12 /htdocs/public/www/includes/EditPage.php(1355): ContentHandler::runLegacyHooks(string, array)

#13 /htdocs/public/www/includes/EditPage.php(1603): EditPage->runPostMergeFilters(ScribuntoContent, Status, User)

#14 /htdocs/public/www/includes/EditPage.php(1237): EditPage->internalAttemptSave(boolean, boolean)

#15 /htdocs/public/www/includes/EditPage.php(427): EditPage->attemptSave()

#16 /htdocs/public/www/includes/actions/EditAction.php(50): EditPage->edit()

#17 /htdocs/public/www/includes/actions/EditAction.php(74): EditAction->show()

#18 /htdocs/public/www/includes/Wiki.php(428): SubmitAction->show()

#19 /htdocs/public/www/includes/Wiki.php(292): MediaWiki->performAction(Article, Title)

#20 /htdocs/public/www/includes/Wiki.php(588): MediaWiki->performRequest()

#21 /htdocs/public/www/includes/Wiki.php(447): MediaWiki->main()

#22 /htdocs/public/www/index.php(46): MediaWiki->run()

#23 {main}

AhmadF.Cheema (talkcontribs)

Change the permissions of file: "/htdocs/public/www/extensions/Scribunto/engines/LuaStandalone/binaries/lua5_1_5_linux_32_generic/lua"

to allow execution.

Or in other words, browse to directory: "/extensions/Scribunto/engines/LuaStandalone/binaries/lua5_1_5_linux_32_generic"

and change the permissions of the "lua" file to 0755.

See: Extension:Scribunto#Installation

Bachounda (talkcontribs)

yeah ! Thank you very much the problem is fixed done :)

Tofiq Kərimli (talkcontribs)

Hello.

The same problem appeared on my site: ( wiki.sheki.site ).


[XQZbPCmD7BJvsNm2suoY3gAAAAY] /index.php?title=Module:Wikidata&action=submit Error from line 52 of /home/ipekchi/public_html/wiki/extensions/Scribunto/includes/common/ScribuntoContent.php: Call to undefined method ScribuntoContent::getText()

Backtrace:

#0 /home/ipekchi/public_html/wiki/includes/content/AbstractContent.php(517): ScribuntoContent->fillParserOutput(Title, NULL, ParserOptions, boolean, ParserOutput)

#1 /home/ipekchi/public_html/wiki/includes/Revision/RenderedRevision.php(242): AbstractContent->getParserOutput(Title, NULL, ParserOptions, boolean)

#2 /home/ipekchi/public_html/wiki/includes/Revision/RenderedRevision.php(211): MediaWiki\Revision\RenderedRevision->getSlotParserOutputUncached(ScribuntoContent, boolean)

#3 /home/ipekchi/public_html/wiki/includes/Revision/RevisionRenderer.php(175): MediaWiki\Revision\RenderedRevision->getSlotParserOutput(string)

#4 /home/ipekchi/public_html/wiki/includes/Revision/RevisionRenderer.php(128): MediaWiki\Revision\RevisionRenderer->combineSlotOutput(MediaWiki\Revision\RenderedRevision, array)

#5 [internal function]: MediaWiki\Revision\RevisionRenderer->MediaWiki\Revision\{closure}(MediaWiki\Revision\RenderedRevision, array)

#6 /home/ipekchi/public_html/wiki/includes/Revision/RenderedRevision.php(175): call_user_func(Closure, MediaWiki\Revision\RenderedRevision, array)

#7 /home/ipekchi/public_html/wiki/includes/Storage/DerivedPageDataUpdater.php(1265): MediaWiki\Revision\RenderedRevision->getRevisionParserOutput()

#8 /home/ipekchi/public_html/wiki/includes/Storage/DerivedPageDataUpdater.php(1235): MediaWiki\Storage\DerivedPageDataUpdater->getCanonicalParserOutput()

#9 /home/ipekchi/public_html/wiki/includes/page/WikiPage.php(1994): MediaWiki\Storage\DerivedPageDataUpdater->getPreparedEdit()

#10 /home/ipekchi/public_html/wiki/extensions/SpamBlacklist/includes/SpamBlacklistHooks.php(31): WikiPage->prepareContentForEdit(ScribuntoContent)

#11 /home/ipekchi/public_html/wiki/includes/Hooks.php(174): SpamBlacklistHooks::filterMergedContent(RequestContext, ScribuntoContent, Status, string, User, boolean)

#12 /home/ipekchi/public_html/wiki/includes/Hooks.php(202): Hooks::callHook(string, array, array, NULL)

#13 /home/ipekchi/public_html/wiki/includes/EditPage.php(1747): Hooks::run(string, array)

#14 /home/ipekchi/public_html/wiki/includes/EditPage.php(2066): EditPage->runPostMergeFilters(ScribuntoContent, Status, User)

#15 /home/ipekchi/public_html/wiki/includes/EditPage.php(1574): EditPage->internalAttemptSave(NULL, boolean)

#16 /home/ipekchi/public_html/wiki/includes/EditPage.php(677): EditPage->attemptSave(NULL)

#17 /home/ipekchi/public_html/wiki/includes/actions/EditAction.php(60): EditPage->edit()

#18 /home/ipekchi/public_html/wiki/includes/actions/SubmitAction.php(38): EditAction->show()

#19 /home/ipekchi/public_html/wiki/includes/MediaWiki.php(501): SubmitAction->show()

#20 /home/ipekchi/public_html/wiki/includes/MediaWiki.php(294): MediaWiki->performAction(Article, Title)

#21 /home/ipekchi/public_html/wiki/includes/MediaWiki.php(860): MediaWiki->performRequest()

#22 /home/ipekchi/public_html/wiki/includes/MediaWiki.php(517): MediaWiki->main()

#23 /home/ipekchi/public_html/wiki/index.php(42): MediaWiki->run()

#24 {main}

Modules can not be created. understand what you wrote. lua5_1_5_linux_32_generic/lua - on my site: public_html/wiki/extensions/Scribunto/includes/engines/LuaStandalone/binaries/lua5_1_5_linux_32_generic/lua . But I did not. "Change the permissions of file" and "change the permissions of the". I can not understand that. How to Do It? Where to Do? Thanks in advance.

AhmadF.Cheema (talkcontribs)
Reply to "The lua binary lua is not executable"
Wgkderdicke (talkcontribs)

I recently updated this wiki here from MW 1.27.17 to 1.31.2. Now I'm experiencing this bug here, too. But it's the Chrome browser instead of the FF/SeaMoneky browser. This is my current Chrome's version: 74.0.3729.169 (Offizieller Build) (64-Bit). The bug rises not every time but then and now and occurs definitely not before the MW update.

I updated Chrome just now. It's version 75.0.3770.90 (Offizieller Build) (64-Bit) now.

AKlapper (WMF) (talkcontribs)
Wgkderdicke (talkcontribs)

It is not any Wikimedia website where I'm experiencing this bug. It is the wiki that I'm running. This wiki was moved to a new server by my provider, then he has changed the PHP version to 7.2 and after that I have updated the MW installation. All this has happend in the last few days. At the moment I'm working on some necessary adjustments. So far, all looks good, even if there is still a little bit work to do. But after the MW update and when I want to save an edited page, then and now this bug occurs in the Chrome browser. From at the end of 2016 I found this here: phabricator.wikimedia.org/T151770. But it's all about Firefox.

AKlapper (WMF) (talkcontribs)
Reply to "Session loss bug?"
Riventree (talkcontribs)

I have just found this page and am almost certainly asking a dumb question that is documented somewhere, and I've read the documentation pages for "Page" and "Text", but there's either not enough, or far too much, data there for my brain to parse.

In short, I'm feeling a bit lost and I'm asking for help.

I am trying to do something that is slightly against the basic wiki premiseː produce a read-only engine that provides lookup-by-title, what-links-here, and search, but no other "actions" whatsoever. Simply adding a new skin won't remove access to the core functionality if someone clever crafts their own url, so I know I need to actually do PHP-level work.

If I understand the mediawiki architecture properly, each page goes from raw (user submitted) wikitext to "expanded" (substituted) wikitext, and thence to actual (x)html. I believe this "core page image" html is stored in the database somewhere (I'm guessing somewhere in "text", but I don't know)

I have many years of programming under my belt, so I'm confident I can muddle my way through once I find the part of code that says "This is the title, give me the HTML". I can handle the PHP, SQL, html, css, javascript et al, but I've been stymied trying to drill down from index.php to the parts of the engine I'm looking for.

Obviously, index.php is the entry point, but the query that actually results in html is hidden deep under the skins and WikiPage (I think) and I'm stuck.

I'm hunting for three bits of code, which i imagine don't look anything like this: :)

Query::GetBodyContent (title, &mw_body_content)

Query::SearchPagesByText(text,&listOfPageTitlesWithMatchText)

Query::WhatLinksHere(title, &listOfPageTitles)

Can someone give me a pointer to the right php file(s) or class(es) to continue my search?

Thank you kindly,

Riventree

Ciencia Al Poder (talkcontribs)

I'm not sure what's your goal. Use MediaWiki but prevent other users to edit pages? Then see Manual:Preventing access.

If you want to start from scratch your own content management system, I guess this will bee too complicated, and it's better for you to not attempt to see how things are done here, because what you want to do is relatively simple on its own having a proper database design.

Reply to "PHP access question"
Asketoff (talkcontribs)

Hi. How I can delete all wiki with all pages?

Malyacko (talkcontribs)
Jonathan3 (talkcontribs)

If you want to keep the wiki installed, would Extension:Nuke be what you need? I've not used it but it looks like what you want - "The Nuke extension makes it possible for sysops to mass delete pages."

Reply to "Delete wiki"

Categories are not updated except using rebuildall.php script

2
ToniBC78 (talkcontribs)

I have the same problem as others with the categories, when I assign a category to a page, it is assigned well, but in the category page it indicates that there is no page. Pass with all categories. I am using version 1.32.1 under PHP 7.3.

I have tried with runjobs.php but it does nothing, the categories remain empty.

I have set the command $wgRunJobsAsync = False in LocalSettings.php and nothing, there is no way that the categories appear.

Only by running rebuildall.php all the categories appear correctly.

I've been reading and testing everything for days and I can not get the categories out automatically, the only way is with rebuildall.

Some solution to try.

Jonathan3 (talkcontribs)

I had a similar problem (with MW 1.31) and updating Extension:Cargo the running Manual:rebuildall.php solved it. The difference as that rebuildapp.php gave an error message identifying the (old version of the) extension as the problem. But I guess it could be a problem with some other extension which you have. Maybe disable them and see if it works.

Reply to "Categories are not updated except using rebuildall.php script"

Pages not added to Categories (setting wgRunJobsAsync and wgJobRunRate didn't help)

3
2001:4B98:DC0:47:216:3EFF:FE3D:888C (talkcontribs)

Hi,


I installed MediaWiki 1.32.1 and created some test pages. Furthermore I created Category:Pages with some descriptionary text and added the test pages to categories (inserting Category:Foo in brackets). I can see the categories at the bottom of each page.


When I now try to access Special:Categories the page shows me the categories, but every page has 0 entries.


When looking for the issue, I found several sites which suggested to run the runJobs script which I did. I also set $wgRunJobsAsync = false; and $wgJobRunRate = 3; in my LocalSettings.php. Both changes didn't help. The site api.php?action=query&meta=siteinfo&siprop=statistics&format=jsonfm shows that there are 0 open jobs.


What coudl be the issue here? Do you have other ideas why pages don't get added to category view?


Thanks

Ciencia Al Poder (talkcontribs)

Note that changing settings like $wgRunJobsAsync = false; etc when there are 0 jobs to run won't add the categories back. If some jobs failed completely to work, or even to be queued, due to a bad extension or problem with PHP, they won't get added again.

Anyway, $wgRunJobsAsync is false by default. I suggest to remove a category from a page, enable the debug log (see Manual:How to debug) and then add again the category to the page, and see if there's some relevant error on the debug log.

Jonathan3 (talkcontribs)
Reply to "Pages not added to Categories (setting wgRunJobsAsync and wgJobRunRate didn't help)"

Custom special page to manage old pages

2
81.82.224.91 (talkcontribs)

Hi, we're wondering how we can manage old pages. We would like to check once in a while which pages of a certain category exist whose last modified date are more than one year ago. We could then ask the owners to validate them to make sure they are always up-to-date. This process is important for some content.


Can this be done with a custom special page? Can I easily create a page that gives me alle pages of a certain category with last modified date between x and y?


Thanks!

Jonathan3 (talkcontribs)
Reply to "Custom special page to manage old pages"

What happened to Close Captioning 🙁

2
Lindamalan (talkcontribs)

Close captioning has disappeared

Malyacko (talkcontribs)

If you explained what "Close captioning" is or was and clear steps where to see "Close Captioning" in MediaWiki then someone might be able to answer.

Reply to "What happened to Close Captioning 🙁"
Scott216 (talkcontribs)

I'm running MW 1.32, PHP 7.0.33, MySQL 5.6.40 with Vector skin. When is use the built in search, most of the time it works fine. For example, if I search on "Restaurant", I'll get search results and the URL looks like this:

http://wiki.mydomain.com/index.php?search=restaurant&title=Special%3ASearch&go=Go


But if I put in a search term where there exists a wiki page with the same name, I get a 404 error. For example, if I search on Automobile, I get a 404 error and the URL looks like this:

http://wiki.mydomain.com/http://wiki.mydomain.com/index.php?title=Automobile


I have a wiki page called Automobile:

http://wiki.mydomain.com/index.php?title=Automobile


For some reason, when my search term matches an existing page, my domain name is listed twice in the URL field.


TheDJ (talkcontribs)

One of the variables in your LocalSettings config is not correct and using a full url instead of a url path component.

Scott216 (talkcontribs)

Any idea which variable? I looked through my LocalSettings file and can't figure out what might be the cause. I recently upgraded to 1.32 from 1.24.

Scott216 (talkcontribs)
Jonathan3 (talkcontribs)
Ciencia Al Poder (talkcontribs)

I think you need to set $wgScriptPath = "/"; not blank

Scott216 (talkcontribs)

Fixed problem by adding

$wgServer = "./";

to LocalSetting.php


I also tried $wgScriptPath = "/"; but that broke everything.

BTW - My wiki is installed in /home/goldthwa/public_html/

and my URLs look like this:

http://wiki.mydomain.com/index.php?title=Automobile

This is how it was setup by Siteground (my hosting provider) back in 2007

Ciencia Al Poder (talkcontribs)

Setting $wgServer = "./"; is a really bad idea. Good for you if it works on your configuration, but this is something that should break the wiki in unexpected ways.

Jonathan3 (talkcontribs)

Manual:$wgServer under the heading "Universal value" states: "In situations where a server URL is subject to change (i.e. frequent MediaWiki installation porting, intranet access, etc.), setting $wgServer to ./ will work without causing CSS not to work."

Ciencia Al Poder (talkcontribs)

That was added by an anon less than 2 years ago. I highly doubt this has been tested thoroughly, specially if you have Pretty URLs like on WMF wikis. It could only work inside browsers where URLs can be made relative, but it won't work in situations where one expect an absolute URL, like on sitemaps, api responses, etc.

Ciencia Al Poder (talkcontribs)

I've removed the "Universal value" section of that page. I've tested it on a wiki with Short URLs (/wiki/Pagename and /w/index.php), and after saving the page you get redirected to literally "wiki/Pagename" without server name nor protocol.

Jonathan3 (talkcontribs)

Thank you for clarifying that and for fixing the page.

Reply to "Search result give 404 error"