This page used the Structured Discussions extension to give structured discussions. It has since been converted to wikitext, so the content and history here are only an approximation of what was actually displayed at the time these comments were made.
Latest comment: 6 years ago3 comments2 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I’ve installed tinyMCE on my installation but for several pages it just doesn’t work. I get a delay, then the tinyMCE menu, but then no text shows up below it for editing (even though there is text, and I can see it by selecting “Edit source” instead of “Edit” (which invokes tinyMCE). I’m running mediawiki 1.31.0, and my server is running 7.3.13 (which I can’t change). Any ideas?
FYI I installed tinyMCE by going to my extensions folder and doing:
(DC on behalf of Andre) Sounds like you installed git master (=unstable development 1.35.x version) of TinyMCE together with an outdated insecure MediaWiki version (1.31.0).
Thank you for trying this extension. Andre's advice is good, however, I recreated your environment (except I'm using PHP 7.1.33) and found that it should work. Unfortunately I was unable to reproduce your problem although I tried a number of complex pages that I use as test cases.
Problems similar to this haver occurred in the past. Usually it is some combination of wiki-markup that breaks the code which parses it into html (eg. a bug as you say). If you go into your browser's 'debug' mode, usually by right clicking and selecting 'inspect', it should display if an error has occurred and in which bit of the code.
If you let me know if there is an error and where in the code it is happening that will help me to find a solution. Even better, if you can isolate the wiki-markup that gives rise to the problem that will be even more helpful.
Latest comment: 6 years ago14 comments2 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The page mentions setting perms for this, but not which perms, where. On a wiki where MediaWiki's "Upload File" works fine for a png, TinyMCE's "Upload/edit file" button, after selecting a file from the local workstation, complains "I'm sorry, you have encountered an unknown error trying to upload this file. If this error persists please cntact your systems administrator". There's nothing in the Apache log -- no error at all. And of course I'm the administrator.
What does happen, instead of the image being uploaded, is this appearing on the page where it was to go, in double square brackets "undefined|right|middle|thumb". I haven't found a way yet to get more useful debugging data out of it. WhitWye (talk) 20:09, 22 January 2020 (UTC)Reply
Hi
Thank you for using this extension and also reporting this problem. There are in fact two problems, the second of which (the wiki code for a 'file' link being inserted into the editor rather than the image displaying) is a coding error and I will upload a fix for this the the master branch on gerrit over the next day or so. To solve the first problem with the upload, however, I will need some more information.
If the error was to do with permissions, files sizes, valid file types, duplicates etc, then the extension would report these explicitly. This error message is caused by the mediawiki API reporting a 'success' code for the file upload but returning an undefined result without either an error or warning response. The result should be an external URL to where your wiki has stored the file and also the link to the uploaded file to use from within a wiki page . As a result of the lack of information from the mediawiki API, the extension is unable to report further details of the error - which is frustrating I know!
However, perhaps with a bit more information, we should be able fix this. The following would help me to try and isolate the problem, which I haven't be able to reproduce, sorry.
the name of the file you were trying to upload (occasionally if there are non latin characters this can cause problems)
would you check the 'files' special page to see if the file was uploaded successfully (sometimes the upload happens anyway)
would you let me know the versions of software and extensions you are using from the 'versions' special page
would you let me know if there were any warnings and errors when you were using the upload dialog before you got the error message
if you are able, can you add the following to your 'localSetting.php' file after the '<php' tag as it will get mediawiki to report any errors it encounters during an upload to the web browser.
Appreciate the help. I tried with a number of .png and .jpg files, all with only Latin characters. Most were quite small. The files did not show up on the "Files" special page. There were no warnings or errors using the upload dialog before the message. I already tried those error reporting settings, and nothing more showed from that.
Installed Extensions shows nothing, which is obviously wrong, since TinyMCE is running (via "wfLoadExtension( 'TinyMCE' );"). Should I back off from 1.35.0-alpha? I was starting with that to try to get Visual Editor running to test it, but that project is just a mess at present. TInyMCE has the great advantage of not requiring such a bloated stack.
A separate question: Can the vertical space taken by the TinyMCE window be set larger? With image uploading fixed, and that expanded, our users here (internal company wiki) should be happy with the upgrade from a much older MediaWiki with CKEditor -- which allows dragging the editing windows to arbitrary vertical sizes, but otherwise is not as polished. WhitWye (talk) 14:30, 24 January 2020 (UTC)Reply
Hi
I think the problem may be with the 1.35 alpha as that is a pre-production, pre-release version as I understand it (see Version lifecycle#Extension lifecycle management). I suspect it is not stable enough yet for anything like production work and it is quite likely there are changes to the API and underlying software versions of tools like PHP. I believe there are users of TinyMCE on versions of mediawiki up to 1.34, but personally I do most of my development and testing on 1.31 which is the current Long Term Stable (LTS) version, which should be supported until June 2021.
To change the displayed height of the editor window there is a setting in the MW_tinymce.js file in the extension root directory which can be used to reset the height:
autoresize_max_height: 400,
I'm currently working on a new version which I hope will replace the current beta version and I will consider if I can make the editor window user re-sizeable in that. As you'll appreciate, I want to focus new feature development on that version rather than the current version :-)
The TinyMCE extension is very much intended as a simple to implement and familiar to use WYSIWYG editor interface, yet with a rich feature set, which will I hope will be even more evident in the next version so I'm glad you are trying it out. Do let me know if you need any further help. I will try to get a patch for the other problem you had uploaded to the Git master over the weekend.
Exactly the same behavior from 1.31.6. It did, on one file, give proper notice that it already existed. But for a new upload, it just goes right to the generic error message. Nothing logged anywhere.
Ah, learned something: It's not enough to change the version, but for some reason Apache must be restarted to avoid partial inheritance -- or is it the browser caching script, or session management on the server? So now with 1.31.6 I get to a new error:
I'm sorry, you have encountered the following warnings trying to upload this file:
You have received the warning thumb
Please correct the errors and try again
At least it's the thumb and not the finger. But what can that mean?
On another try I get to the point where, within double square brackets, is the code that should be there if this were the wiki code version of the page:
File:Bluesteal.png|right|middle|thumb -- which then does pull the file in once saved, and displays the image during a subsequent edit, which it did not do on first insertion. Definitely progress. Is this overall the expected behavior?
Once a file is on the page, going in again to edit its properties by double clicking on it results in adding a duplicate of the file to the page. Is this to be expected?
Firefox duplicated the image when trying to move/resize it on the page. Chrome leaves it single, but it picks up extra code when saved, which is also a problem in Firefox (both Linux here). First there's a font spec in angle brackets, then also in angle brackets:
The "src =" part actually has the image displayed between the quotes. The angle brackets are actually the HTML codes to display those, rather than really being angle brackets at the code level.
Should I take it that TinyMCE 4 just isn't good with images? Is 5 improved in this?
Sorry for delay - for some reason I wasn't getting notified of your further questions :-{.
As for inserting the wiki code when first uploading - did you manage to download the patch that I mentioned earlier? You can find it here.
It's been a while since I used the image upload extensively so some other changes may have upset it but it should work better than you are experiencing. It can be a little convoluted, in part because of the checks and warning mediawiki makes, but it shouldn't be crashing or dumping html code into the page. Your additional information ios very helpful so I'll investigate a little more.
B.T.W. did you retry mediawiki 1.34 after you resolved the caching problem? I know there are other users using 1.34 on a regular basis so you should be able to use it O.K. Caching can cause issues when the code changes, as you found, both at the client and server end so if you change any code (js or css) it's often advisable to purge the caches. To do this at the client end I often find it best to go into the browser's 'inspect/debug' mode and then follow the recommended procedure to purge the cache and reload the page.
Much appreciate your help and efforts here. Meanwhile I've finally got Visual Editor working, so I'm on to trying to work out why CirrusSearch and friends fail to work by date order in 1.34. Hope to see your work with TinyMCE keep it in contention, as Visual Editor is overly much in many contexts, and underdocumented.
As I suspected an earlier edit I had made had caused this problem :-( I've submitted some changes that should fix the problem so, should you wish to try TinyMCE at some time again, it should now work as you might expect. The changes are waiting review before they are merged to the master branch but if you (or anyone else for that matter) need to see what the changes are you can get a patch at https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/TinyMCE/+/569318/
Latest comment: 6 years ago2 comments2 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Hello -- New user to MediaWiki so I'm sure this is related to my own errors, yet I could use some help.
After installing the TinyMCE extension, I received this error:
Original exception: [Xi8Zvty3mPSGkoC@gJrWrQAAAAs] 2020-01-27 17:11:26: Fatal exception of type "UnexpectedValueException"
Exception caught inside exception handler.
Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.
Welcome to mediawiki and thank you for (trying to) use this extension. Also apologies for the delay, for some reason I wasn't notified :-(
I wonder if you tried adding the following line to the LocalSettings.php file, which is located in the root directory of your mediawiki installation?
$wgShowExceptionDetails = true;
This will cause extra debugging information when errors are encountered.
You can also add the following lines to get more error information. These lines can be removed again once everything is working properly.
error_reporting( -1 );
ini_set( 'display_errors', 1 );
From what you have told me so far, the problem may relate to a mismatch of software versions. If you navigate to the special pages page (a link can be found on the menu panel to the left) and locate the versions link on that page, you will be given a lsit of all the various modules loaded including their versions. If you can let me have that information, it will help with identifying the problem.
Latest comment: 5 years ago3 comments2 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I was able to add the image to the page, but I cannot move it. It always display on the right side of the screen. Please assist.
You can either change the layout when you load the picture (if you use the dialog rather than drag/drop) or after it has been loaded.
When initially loading, the layout options are on the second tab of the dialog which is labelled 'image' and there you can set the horizontal alignment. If you want to change the layout later, you can do this by double clicking on the image, which should bring up the dialog again. In this case the layout options are on the front of the dialog.
The default behaviour in mediawiki is to display an image on the right, which is why the extension uses this default too. Hopefully the instructions above will resolve your issue but do let me know if you need more help?
Latest comment: 5 years ago8 comments2 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I can copy and paste text with hyperlink, the edit mode look great, but after saving, the hyperlink has <a href" added and it's no longer the hyperlink. For example, if I search ABC from google then copy the link, from edit I will see ABC Home Page - ABC.com and it's clickable, after saving, it shows <a href="and the website" ping="/url?sa=t&source=web&rct=j&url= and the link to the page here, MediaWiki consider this as spam so I have to type this line">ABC Home Page - ABC.com</a>
Hi, I think this may be related to the other paste problem you noted below. I've been working on this and think I have it working now, both for the original problem and the one you note above. Rather than just patch things up, I've tried to make things a bit more robust. which is why it's taken a few days. Now all I have to do is remember how to upload this to mediawiki :-(
It always seem to take me a day to get the process in Gerrit working!
I've just done a bit more testing and came across a couple of other strange things with paste/drop so it will be another day or so to get this done, sorry. DuncanCrane (talk) 18:09, 12 March 2020 (UTC)Reply
Hi there again.
I've now added a patch to Gerrit that I hope addresses the link problem above and also bugs with the drag/drop cut/paste auto upload of images.
This will need to be reviewed and accepted before it is applied to the 'master' branch but if you need/want it quicker you can download the patch here
Latest comment: 5 years ago4 comments2 people in discussion
RESOLVED
Latest release V1.0 of this extension now uses version 5 of TinyMCE
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Love this extension!
Was wondering if you guys are looking at TinyMCE 5 to implement.. iframe is gone (yeah!) and it looks like a big improvement over 4.x Sen-Sai (talk) 10:00, 26 March 2020 (UTC)Reply
Hi Sen-Sai
Your question is timely. I am just starting to look at this and so far I am hopeful it won't take verylong. I've also been working on a number of improvements to the core which I believe make it more stable and maintainable, as well as covering a lot more of the mediawiki syntax. This is in the final stages of testing and I hope to release it soon.
Latest comment: 5 years ago5 comments2 people in discussion
RESOLVED
Problem resolved
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
When TinyMCE is installed, upon trying to create a new discussion page for any page or creating new discussion topics, TinyMCE editor is not used. Is there something I'm missing or is this somehow configurable?
Is it possible to make all edit actions default to `tinymceedit`?
NOTE: When creating a new discussion page, the action is `edit` and when creating a new topic, the action is also `edit` and not `tinymceedit`. Thanks! X-Savitar (talk) 16:26, 17 June 2020 (UTC)Reply
Hi
I'm really pleased you are giving this extension a try. I can certainly do some investigation, and consult with those who know more than I, to see how this might be done.
You may also be interested that I'm very close to releasing a major upgrade to the extension which makes use of the latest versions of TinyMCE and also provides improved coverage of wiki text markup. If you are interested in using the extension long term it might be worth you using this new version, which can be found here https://github.com/duncan-crane/TinyMCE/tree/Upgrade-to-TinyMCE-5.
If you do try this, be sure to download the 'Upgrade to TinyMCE 5' branch and not the 'master' branch.
I'll post something here on your question about Talk pages when I have some more information
My friend Yaron has created a patch so that the TinyMCE editor will load when creating new Talk pages and adding New Topics. It should be in the latest master copy in Gerrit if you'd like to try again?
Please do let me know if you've any other questions.
I am currently working with some others on an extensive programme of testing. Provided the testing doesn't throw up anything that requires a major development effort, I hope to release the next version by the end of July. DuncanCrane (talk) 14:37, 1 July 2020 (UTC)Reply
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.
Latest comment: 5 years ago12 comments3 people in discussion
RESOLVED
I believe this should be resolved by the latest release V1.0
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I got TinyMCE installed and its pretty amazing and fairly easy to use, BUT somehow some pages are not loading into the editor or not showing.
Is there a limit on how big a page should be in order to get loaded?
I also have a cache set up,, could that maybe a problem?
It's great you are giving the extension a try and thank you for raising this question.
This occasionally happens when the editor encounters a '|' characters in the text. Normally this is when people are using it in forms, but I have known it to happen elsewhere. Would you check the text and see if there are any '|'s and try 'escaping' them by using the {{!}} template instead?
If this doesn't work, the if you can let me have the wiki text content of the page, I can try and reproduce the problem.
You may also be interested that I'm very close to releasing a major upgrade to the extension which makes use of the latest versions of TinyMCE and also provides improved coverage of wiki text markup. If you are interested in using the extension long term it might be worth you using this new version, which can be found here https://github.com/duncan-crane/TinyMCE/tree/Upgrade-to-TinyMCE-5.
If you do try this, be sure to download the 'Upgrade to TinyMCE 5' branch and not the 'master' branch.
The new version is also fixes the '|' issue mentioned earlier so it may be a solution to your problem too.
I have installed the TinyMCE from Upgrade-to-TinyMCE-5 branch but is gives error on SpecialPages and also no tool bar in TinyMCE edit option on pages.
SpecialPages Error:
[e943dd9c63c146a8353747db] /index.php/Special:SpecialPages Error from line 382 of /var/www/devwiki/includes/specialpage/SpecialPageFactory.php: Class 'TinyMCEUploadWindow' not found
I'm sorry that didn't work and thank you for trying. The Special pages issue was pointed out to me earlier in the week and a new release will be posted later today or tomorrow. I will also add some notes on configuration to the GitHub summary page as I think those on the mediawiki extension page may not apply to the new version. Sorry for any inconvenience.
I have downloaded latest files from Upgrade-to-TinyMCE-5 but still the issue with Special:Pages and TinyMCE Tool bar didn't resolve.
I have placed the TinyMCE folder under extension folder and made entry in LocalSettings.php as per README File. Can you let me know if there is anything I have missed. Srikanth 4455 (talk) 08:44, 29 June 2020 (UTC)Reply
Hi Sri
Thank you for persevering and I'm sorry that didn't work. I checked my latest release to that branch and somehow I didn't include the fix for the special pages, so I really am sorry.
I will submit another release over the next day or so, but you could try removing the following line from the extension.json file in the root directory of the TinyMCE extension. You'll find it on or around line 175.
I looked into some of the cases were the editor did not load the texts. There is no "loose" "|".
It seems the "|" to construct a table is ok ?! When I write the contents of a tablerow next to each other, like this: "| cell 1 || cell 2 || cell 3", is that different for the editor to load, than writing the tablerows underneath each other?
Besides that I actually found which elements causes the editor not to load:
1. I use the extension Extension:Tabber and if I put all my contents directly inside the tabs, the editor will not load, it doesn't matter how much self written text is in the tab. But if I put another page (as an include) in the tabber, the editor will load.
What the editor does when its actually loading the tabbers, it puts everything inside the "<tabber>" tags in the "wikimagic" function
2. when I divide a page in columns via wiki markup and I than try to edit just a section of the page containing a part of that markup the editor will also not load. when I load the entiere Page its fine. I guess this is due to what you assumed with the "|" character and the editor doesn't recognise this as a part of the page deviding.
Another wierd thing happens by using the wiki markup "<nowiki>" and "#" inside it. That creats very interesting result in the editor. I solved that by using "<source>" instead. I guess that will be solved with your upcoming update?
I tried to install the current development of the update 5, but somehow its not working at all. I will wait till its fully released. Xaase (talk) 09:43, 23 June 2020 (UTC)Reply
Thanks, that's very helpful. I'm not familiar with extension tabber so I will have to look into that. I suspect you may be right about the '|' treatment. I have to admit the 'old' version was mainly good for simple to medium complexity wiki markup. The new version has been tested against a much fuller set of markup (based on mediawiki 'help' pages and seems to handle things better.
I realised now that I should provide some details about configuring the extension on the GitHub pages as it has changed in some respects. I think the new version will be released before the end of July, but I will put some notes in GitHub in case you wish top try again. DuncanCrane (talk) 07:16, 26 June 2020 (UTC)Reply
I tested a bit more with that issue and came to the following observation:
the "wikimagic" seems to have a maximum of characters (?) but I couldn't pin point exactly where the limit is ...
I'm sorry this isn't proving straightforward to find a solution. Would it be possible for you to use the debugger or inspect function on your browser to see if any errors are being reported? This might help identify the problem.
I looked at the Tabber extension. The way that the TinyMCE extension works is that anything between the <tabber> tags, or {{ }}, is sent to the mediawiki api for processing and the equivalent html returned to the editor in a protected block that can only then be edited using the source editor menu options.
This is a general feature for all mediawiki templates, tags, parser functions etc. because they are instructions to mediawiki that aren't understood by a standard html interpreter. I should say the newer version is more flexible as it will allow editing of html embedded in the wiki code, whereas the old version treated it in the same way as other mediawiki tags.
If you need the TinyMCE extension to interpret the code within the <Tabber> tags to create html that TinyMCE itself can edit, currently that would probably require a plugin to be created (even in the latest version). Even then it may be difficult to recreate the tabbed structure within the editor window.
There may be some other possibilities which would need testing, including:
swapping to using the Headertabs extension, although in the TinyMCE editor the page is displayed as a page with a number of headings rather than tabbed. When saved mediawiki will display the page with tabs.
the new version will have a capability to edit areas of the page in situ without selecting the edit tab, which may let you edit the text between the tabs directly.
I'm also working on a plugin for the TinyMCE editor which will interpret templates, tags and parser functions creating forms that allow the user to edit parameters that are passed to these structures.
Latest comment: 5 years ago36 comments2 people in discussion
RESOLVED
Spaces at the start of lines in html text embedded in the wiki page were causing an error. This has now been fixed on the development Github site master branch (release 1.0.3+). This fix will be included in the next official maintenance release on mediawiki Gerrit v1.1 in Q1 2021
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
It takes up to 45 seconds to load when editing larger pages, which is way too long. Is there a way to make it faster? WinCache is installed and MediaWiki's file cache is enabled. Leaderboard (talk) 20:20, 11 July 2020 (UTC)Reply
Hi
I'm sorry I haven't passed this way for a while and hadn't spotted you question earlier. There are two likely reasons for the slow loading. The first is the initial load of the javascript and css files, The second is that your page is causing many calls to the mediawiki api parser to interpret parser functions, template calls etc. In either case 45 seconds does seem pretty extreme.
If it is just the initial load of the editor that is taking the time (ie doesn't vary on page size) then would you check your browser's debugger to identify which modules are causing the delay?
If it is on large pages only (or pages with many parser functions etc) then you may want to try the current beta development version (see posts below for where to get the current development version). This newer version will be released in the next month or two, if you'd prefer to wait for an 'official' release?
The newer version batches up nearly all calls to the mediawiki api parser into a single call executed when loading a page into the editor which removes delays introduced by executing many separate calls to the api. This greatly speeds up loading of such pages. Because of the volume of changes needed to introduce this capability, unfortunately, I'm not able to retrofit it to the older version.
Yes, it mainly happens on long pages, and occasionally fails to load (returns a blank page) in extreme cases. I'll consider trying your beta and will let you know if I run into further issues.
EDIT: I'm getting an internal error on MW 1.34.2 -
MediaWiki internal error.
Original exception: [ce6f52f30991a13c81416fb0] /wiki/index.php?title=Main_Page MWException from line 164 of D:\public_html\betaarchive\wiki\includes\Hooks.php: Invalid callback TinyMCEHooks::addToViewPage in hooks for OutputPageBeforeHTML
Exception caught inside exception handler: [ce6f52f30991a13c81416fb0] /wiki/index.php?title=Main_Page MWException from line 164 of D:\public_html\betaarchive\wiki\includes\Hooks.php: Invalid callback TinyMCEHooks::modifyTalkPageLink in hooks for SkinTemplateTabAction
Hi again and thank you for the quick reply. These two callback functions should be defined in the TinyMCE.hooks.php file in the extension root. Would you check this is the case on your system? If they are, it does look for some reason that your system is not picking these up given the error message.
B.T.W. I should have mentioned, there is a sample of the config for LocalSetting.php in the README file on github and I have just added some notes on how this works.
Please do let me know if you are still getting problems
No dice. I couldn't find anything called "TinyMCEHooks::addToViewPage" in the hooks.php file, but can see "addToViewPage", not sure if that's what you are looking for (and also checked on the GitHub copy). I tried both configs, the "barebones" one (with only the extension loaded), and the one with all changes, but both return the same error. Not sure how to go from here.
Hi, yes that's right. The call back functions in 'TinyMCE.hooks.php' are called 'addToViewPage' and 'modifyTalkPageLink'. The 'TinyMCEHooks:', I believe, is to tell mediawiki where to find the call back functions. What is strange is that there are several other hooks defined in 'TinyMCE.hooks.php' which aren't causing errors, so mediawiki is finding and processing the hooks ok, apart from these two.
I tried downloading and testing from Github but all works ok for me (I am using 1.31, but I have colleagues who are currently using on 1.34 successfully).
There are a couple of things you could try. First, it may be a conflict with another extension, so it might be worth disabling other extensions and see if that makes a difference. The second thing I noticed is that the 'addToViewPage' call back doesn't end with 'return true' where all the other call backs do. You might try putting 'return true' at the end of the 'addToViewPage' callback in 'TinyMCE.hooks.php'
Original exception: [b083c004a5d99b107f880a21] /wiki/index.php?title=Main_Page MWException from line 164 of D:\public_html\betaarchive\wiki\includes\Hooks.php: Invalid callback TinyMCEHooks::addToViewPage in hooks for OutputPageBeforeHTML
Exception caught inside exception handler: [b083c004a5d99b107f880a21] /wiki/index.php?title=Main_Page MWException from line 164 of D:\public_html\betaarchive\wiki\includes\Hooks.php: Invalid callback TinyMCEHooks::modifyTalkPageLink in hooks for SkinTemplateTabAction
Unlikely, because I first renamed the folder to something like TinyMCE_old before copying.
Edit: I decided to try it on a localhost installation. While that one no longer complains, ... nothing happens when I click Edit (or Edit Source). Only the WikiEditor one appears. And I did set TinyMCE to be enabled in LocalSettings.php. Leaderboard (talk) 16:41, 28 July 2020 (UTC)Reply
Thanks again. It is strange that the edit I suggested didn't result in an additional error message as indicated. This would suggest that mediawiki isn't looking at the file you edited.
With the installation on localhost, if error messaging in the wiki is enabled, you should have the same messages as on you remote site. Would you use the browser debugger to see if there are any javascript errors being reported?
Ok, as far as I can see, on your remote site your wiki appears to be using the wrong version of TinyMCE.hooks.php. I believe this because you didn't get a message 'Invalid callback TinyMCEHooks::disableWikiEditor' when you made the change I suggested.
What I suggest you do now is:
1. delete all versions of the TinyMCE editor form your system,
4. flush all caches using whatever mechanism applies to your browser
5. put the browser into it's debug mode
6. load up your wiki
If you still get the error, then would you let me have the details of all the versions of what is loaded in your wiki (using the special:version page)?Thanks DuncanCrane (talk) 08:02, 30 July 2020 (UTC)Reply
For the tables that don't render correctly, would you be able to let me have the wiki text version of the table so I can try to reproduce the problem, and solve it hopefully? If you can reduce it to the minimum necessary markup to reproduce the errors that would help :-)
For the time to load, assuming you are familiar with your browsers debugger, are you able to look at a 'network' load times graph or similar? I'm interested in the time it takes to load a page from when it starts to load 'theme.js' to completion of the page load when the page contains the editor.
I'm using a hosting company server over the internet and my initial load time for the editor (clearing cache and hard reload) is about four seconds and , once it is memory, it takes about 0.5 seconds to load on other pages or refreshing the current page. This is with a page with only about a screen full of content and not many links or templates.
If you can bear with me, we will be drilling into this data to see if we can isolate exactly where the delays are occurring. If you are not comfortable with this level of technical activity let me know?
By the way, did you find what was causing the problems before?
Unfortunately, I don't quite know what was causing the problems before, in fact I left it back then, and was pleasantly surprised to see it working when I tried again the previous day.
I can send you the table markup, but it would be too large to send here, if you want I can use your talk page or email if that's what you prefer. Same goes for the loading graph.
I think the table issue is related to TinyMCE being slow - it probably reaches some kind of limit and stops there. We are using a dedicated hosting server by the way, so raw speed isn't an issue. Leaderboard (talk) 17:20, 27 November 2020 (UTC)Reply
Thanks, Leaderboard.
Funny that but I'm pleased it's working for you now anyway.
I'm assuming that you are now using the 'official' release V1.0 from here which was released earlier this week? There have been quite a few fixes since you last tried :-)
Hi Leaderboard, thanks I have the example wiki text.
I'm not sure if it copied correctly as what is there doesn't seem to be a table as such, as it only has an html table opening tag and now row, column or cell tags?
As it's quite early, my service is running a bit faster today :-). This page loaded in the TinyMCE Editor without the debugger in under 2 seconds. With the debugger running, so I can see the relative load speeds of different modules, loading the page and editor took 4 seconds on initial load and under 1 second once already in memory.
I have noticed some strange formatting artefacts in the TinyMCE editor which don't match the rendered wiki page which I'll have a look into later,.
I don't think there is anything, per se, in your page as it is currently that causes TinyMCE any performance problems. I have users with tables of several thousands of cells in a table that find performance is pretty good. As mentioned above though, maybe something got lost in the copy and paste?
I initially loaded it and it took 8 seconds which seemed way too long. Also the formatting was incorrect as you said too.
I noticed that your table cells each have a space in front of them. I removed these and it loaded so quick I hadn't even started to time it, and formatting was perfect :-)
So what we have is a bug, fortunately. In normal wiki text, a space before a line, or every line in a block, results in the line(s) being converted into a <pre> block when the page is rendered, which you probably know. However, if these lines with spaces occur within an html construct in the wiki text, they are ignored by the mediawiki parser when creating the page to render.
I was aware that spaces at the start of lines in embedded html should be ignored and have logic that is meant to deal with it, but for some reason that doesn't seem to have worked with embedded html tables! So what we are left with is a bunch of table rows with <pre> blocks in them. The html validator within TinyMCE knows this isn't valid html and tries to fix it. So what it does is put all the <pre> blocks in the page before the table and then a table of just headers after. That explains the weird formatting, at least.
I'm not sure yet why it was taking so long processing the <pre> blocks. I'll have to investigate that further, but if I fix the space at start of lines in embedded tables, that at least should get you up and running.
(edited) Oh BTW, the TinyMCE editor interface will convert embedded html table markup to wiki table markup. Once the page is rendered it should look identical, of course. This is because html and wiki table markup can't be used together in the same table so it was easiest to standardise on just one. Wiki markup takes less space and is possibly clearer.. DuncanCrane (talk) 13:39, 28 November 2020 (UTC)Reply
Hi Leaderboard
I just added a fix for this, and a few other minor bugs, to the master branch on Github here
This is the development repository rather than the 'official' release on Gerrit. There will be a maintenance release to Gerrit in due course, but you might want to try out this fix now?
If you do, please let me know how it goes and if you experience any other problems.
Sorry, not yet. You possibly missed that I put the changes on my Github master branch (see post on 29th Nov above for link). There's a few other minor fixes and I plan to update Gerrit once my Dutch chums have regression tested these, probably early in the new year now. DuncanCrane (talk) 11:59, 13 December 2020 (UTC)Reply
Hi Duncan, tried it and the bugs seem to be fixed. However, on the top there appears to be a stray ⧼tinymce-notice⧽ line on top, but functionality isn't otherwise affected. Leaderboard (talk) 10:20, 22 January 2021 (UTC)Reply
Hi Leaderboard, sorry I didn't see this earlier.
It's great that the bug is now fixed, thank you for persevering with it.
The appearance of ⧼tinymce-notice⧽ would suggest there is a label 'tinymce-notice' in the user interface that has no equivalent translation in the TinyMCE/i18n translation file for the language you are using. This would be en.json for english wikis.
Would you be able to provide a little more information to help me locate the problem, as it is not something I've come across myself? The most helpful would be to give me a screen capture of where it appears in the user interface. If you can also go into your browser debug mode and let me have a copy of the html element that cause the ⧼tinymce-notice⧽ to display that would also be very helpful.
Unfortunately I'm not able to find that xpath (possibly why I don't get the tinymce-notice either). Are you able to give me an id or class for the element?
The message 'tinymce-notice is used when creating the content of a page. I'm not sure why as I didn't write that bit of the code :-( but I suspect is possibly there for use by an extension that uses TinyMCE. Still the good news is that the message by default is empty.
In the file 'en.json' in extension directory '/i18n' the following should be one of the entries:
"tinymce-notice": "",
This is present in the en.json file in GitHub so I'm a little perplexed that you get ⧼tinymce-notice⧽ as this should have been replaced by the empty message from the en.json file.
Would you mind checking the en.json file for this message and, if it's not there, would you mind adding it to see if the message then disappears?
Great. Sorry, for some reason I must have removed the language files between v1.0.1 and v1.0.2. Let me know if you hit any other issues :-) DuncanCrane (talk) 11:51, 29 January 2021 (UTC)Reply
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.
Latest comment: 5 years ago3 comments3 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Hi sorry for delay responding. Thanks for pointing that out. The release policy is 'master' which means the current version (for Mediawiki 1.34) should support prior versions from the release identified on the Extension page (currently Mediawiki 1.31+). The version releases are generated automatically so I'm not sure how to rectify this.
Latest comment: 5 years ago2 comments2 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
First, as in title, the version page shows all extensions except for TinyMCE.
Second, I use Minerva skin and unlike vector, it shows no "Edit source" button and the "Edit" button instead works like "Edit source" button in vector. Deadly Artist (talk) 11:22, 7 August 2020 (UTC)Reply
Hi, thanks for letting me know.
The version number is declared in the file extension.json which is in the root directory of the extension. It should contain the following, which is used by special:version
"@Note": "When updating this file please also update TinyMCE.php with the same changes.",
"name": "TinyMCE",
"version": "0.3",
"author": [
"Ephox",
"Hallo Welt",
"Duncan Crane",
"Yaron Koren"
],
If this is present, the version number should appear in Special:version. If it doesn't then you may have a problem with your download? I'm currently using 1.31 and it displays OK.
I'm not sure I understand if you are not being shown the tab for editing TinyMCE at all or if it is just that the documentation applies only to Vector, would you mind clarifying?
Latest comment: 5 years ago2 comments1 person in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Hi!
I was able to install and use TinyMCE in MediaWiki 1.33. It worked fine and is a great solution for me! However I'm upgrading to Mediawiki 1.35 and now the Editor does not show when I click in the proper edit tab but all I can get is a text editor. An clues, please?
Latest comment: 5 years ago49 comments8 people in discussion
RESOLVED
Issues resolved in V1.0 of the TinyMCE extension. Currently bug fixes can be found in the development master branch on Github her https://github.com/duncan-crane/TinyMCE
These will be included in the next maintenance release of the extension on Mediawiki Gerrit which will be numbered 1.0.1
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I drag and drop an image into the editor. First a loading bar appears briefly
Shortly after that, a modal is included:
"I'm sorry, you have encountered an error trying to upload to this wiki : File upload parameter "file" is not a file upload; be sure to use multipart/form-data for your POST and include a filename in the Content-Disposition header.. If this continues please contact your administrator"
Thank you for trying this extension and I'm sorry you've experienced some problems. You might like to try the new version released earlier today. DuncanCrane (talk) 11:51, 19 November 2020 (UTC)Reply
Thanks for your feedback.
After upgrading to the new version nothing happens. I get the default editor and not the Tiny Editor.
I'm not sure when you mention the hook you also checked you'd enabled TinyMCE as part of your personal preferences, but assuming you have, would you next do the following.
Go to a wiki page and open it using the 'edit' tab.
'right' click in the browser window and choose 'inspect' (if you are using Chrome) or 'inspect element' (if you are using firefox).
Then refresh the page and check the 'console' tab in the inspector. Would you let me know what messages you receive in the console, if any?
Also a couple of other things. Above you say you are using MediaWiki 3.1.5. By that did you mean 1.35?
Also in your personal preferences, have you switched off Visual Editor?
sorry i was useing a translator. my english is not the best ^.^
the console says following:
[9ac603d9d1ce3a654e702306] /load.php?lang=de&modules=startup&only=scripts&raw=1&skin=pivot BadMethodCallException from line 851 of --path--\includes\session\SessionManager.php: Sessions are disabled for this entry point
Thanks - seems to me your English is pretty good :-)
The errors don't seem directly related, as you said, but it may be that something else is interfering with the TinyMCE load. You could try adding the following to your LocalSetting.php just after where you have $wgTinyMCEEnabled = true;
$wgTinyMCESettings = array(
".tinymce, #wpTextbox1" => array (
"tinyMCEDebugFlags" => array(
'settings' => 'false',
'debug' => 'true',
'anteOnBeforeSetContent' => 'false',
'anteOnGetContent' => 'false',
'anteOnPastePostProcess' => 'false',
'postOnBeforeSetContent' => 'false',
'postOnGetContent' => 'false',
'postOnPastePostProcess' => 'false'
)
)
);
If you do this and reload the editing page as described above, the process should stop in the debugger when it is initialising TinyMCE. If it doesn't then it is likely that TinyMCE hasn't been loaded for some reason.
Maybe you could also try disabling any other user specified extensions and configuration in LocalSetting.php so we can make sure there aren't any conflicts?
Another thing you could try is to add the following to the top of your LocalSetting.php file to see if mediawiki is getting any other errors?
Something else you could try is to change the url in the address bar of your browser. If you edit a page you will see something like this in the address bar.
Talk:Main_Page&action=edit
If you then change the '=edit' to '=tinymceedit' and hit return your wiki should load the TinyMCE editor if it is available.
the first adjustment with the array did not show any effect. only the wiki standard editor was displayed.
after that i deleted all additional entries in the localconfig. so the above mentioned error with the load was not there anymore. but this did not change the behaviour of tinymce.
adjusting the querys from action=edit to action=tinymceedit worked. i had to click on the debugger a few times during loading. the upload of pictures worked too.
can i get a grip on the fact that i can access the editor without special tinymceedit input and that it runs without debugging steps?
Great, some progress. At least we know that the TinyMCE editor is loaded. To remove the debugging steps all you have to do is remove the array in LocalSettings.php. However, we might want to hang on to the debugger steps for a while until we resolve the problem at least.
I'm not sure how familiar you are with mediawiki programming so if the next paragraph doesn't mean anything to you, just ignore it :-)
The TinyMCE extension uses hooks into mediawiki in order to create the edit links. I suspect that for some reason, the TinyMCE extension is not recognising edit links so isn't changing them to call the TinyMCE editor. When you hover over a 'red link' on a page it should have 'pagename&action=tinymceedit' where pagename is the name of the page being linked to and not 'pagename&action=edit'.
I see above that you are using the 'pivot' skin so I wonder if this maybe where the problem is? Could you try switching to the 'vector' skin, just for now, to see if you still get the problem? DuncanCrane (talk) 15:03, 23 November 2020 (UTC)Reply
hello and thanks for the feedback (:
i have already deleted the array during the tests with tinymceedit. the debug steps appear nevertheless.
when i click on a red link hover the following appears: index.php?title=Testpage&action=edit§ion=1
activating the vector skin did not change the behavior.
It would be useful to know what lines in the TinyMCE editor that the debugger is stopping on. Perhaps you could give some examples, thanks?
B.T.W. did you purge the cache after switching to the Vector skin? Sometimes it takes a while for mediawiki to register a switch?
I presume that you are still getting the unrelated error printout that you reported above? Would you let me have the first few lines of that printout when you have the vector skin installed? They should look similar to:
[9ac603d9d1ce3a654e702306] /load.php?lang=de&modules=startup&only=scripts&raw=1&skin=pivot BadMethodCallException from line 851 of --path--\includes\session\SessionManager.php: Sessions are disabled for this entry pointDuncanCrane (talk) 17:29, 23 November 2020 (UTC)Reply
hola duncan,
following lines were triggered by the debugger:
load.php - line 29:
console.log("TinyMCE Extension version "+v+" Debug Log on selector "+id+" for "+scope+" at "+d);console.log(print_r(text));console.log("END LOG");console.log("");}if(tinyMCEDebugFlags.debug='true')debugger;}
yep, the error still appears:
[2389ac30680e13413bd1b14f] /load.php?lang=de&modules=startup&only=scripts&raw=1&skin=vector BadMethodCallException from line 851 of sitenameincludes\session\SessionManager.php: Sessions are disabled for this entry point
The appearance of those debug statements when the array is not set is a bug, well found:-)
The code 'if(tinyMCEDebugFlags.debug='true')debugger;' in the output you reported should read 'if(tinyMCEDebugFlags.debug=='true')debugger;' so I will put a patch in for that.
This wouldn't cause a problem with the editor though. The error being reported isn't caused by the TinyMCE editor, at least not directly as far as I can tell from the backtrace. However, it does appear to be generated from line 208 in your LocalSettings.php file where it appears there is an function call 'User->isAllowed(string)'.
This function call was deprecated in MW 1.34 which may be why you are getting that error and I guess it may be possible that this is then affecting the way TinyMCE is trying to process the 'red links' to point at the TinyMCE editor.
I had something similar and was given the following link for an example of how to replace this function call using the permission manager here
Would it be possible to try that fix, or at least temporarily disable the code including the 'User->isAllowed(string)' to see what happens?
I also tried using the pivot skin but it caused the browsers local storage to be exceeded. This is a strange condition because it actually has to be manually cleared else it will persist across all browser sessions. It doesn't help to clear the cache or even reboot the system. Also it is not reported as a fatal error, just a warning. This error was preventing some extensions loading properly including TinyMCE. When you switch to the vector skin, it may be worth clearing the browser's local storage. Entering something like localStorage.clear() in the console should do the trick. DuncanCrane (talk) 11:24, 24 November 2020 (UTC)Reply
hola duncan,
you were right. line 208 caused the error. after removing it, the wiki loads without error.
thanks for the workaround - i will have a look at it in a moment.
but this did not change the tinymce behaviour. when i click on edit the normal editor appears. if i enter action=tinymceedit in the query, the correct editor appears and seems to work correctly - except for the debugger that comes all the time.
i have just downloaded and integrated the latest version of the vector skin.
as soon as the skin is activated, i unfortunately always get an error:
Fatal error: Uncaught Error: Call to undefined method SkinVector::getPortletData() in sitename\skins\Vector\includes\SkinVector.php:273 Stack trace: #0 sitename\skins\Vector\includes\SkinVector. php(233): SkinVector->getMenuData('navigation', Array, 3) #1 sitename\skins\Vector\includes\SkinVector.php(133): SkinVector->getTemplateDataSidebar() #2 sitename\includes\skins\SkinMustache. php(59): SkinVector->getTemplateData() #3 sitename\includes\skins\SkinTemplate.php(144): SkinMustache->generateHTML() #4 sitename\includes\OutputPage. php(2615): SkinTemplate->outputPage() #5 sitename\includes\exception\MWExceptionRenderer.php(153): OutputPage->output() #6 sitename\includes\exception\MWExceptionRenderer.php(65): MWExceptionRenderer::reportHTML(Object(Error)) #7 sitename\includes\exception\MWExceptionHandler.php(106): MWExcepti in sitename\skins\Vector\includes\SkinVector.php on line 273
so i don't get to the place to test anymore.
i have loaded the cache with CTRL+F5 before and emptied the cache with the browser for testing. Now also with your variant. Unfortunately this does not change the problem. :(
So I now have pivot working on my MW 1.35 site. Clearing local storage fixed the problem I was having there :-)
On my site, everything is working as expected with the TinyMCE editor being called for new pages and existing pages as expected and the 'edit source' action being added to access the wikitext editor. It even works in Page Forms!
This suggests that there may be a conflict with options you have set for the pivot skin or with other config or extensions you have installed. Is it possible to disable all user config and extensions, apart from the Pivot skin and TinyMCE, and try that? I'd also recommend that you clear local storage again after disabling the other config but before reloading your wiki. DuncanCrane (talk) 15:07, 24 November 2020 (UTC)Reply
Thanks for your feedback.
I have now done a complete cleaninstall of the WIKI. Vector works now. TinyMCE unfortunately still not. It is activated and is displayed correctly on the version page.
When I hover the mouse over the edit link, I get index.php?title=Testseite&action=edit§ion=1 displayed.
If I click on it, I land on the edit page. But there I see the normal editor again and not TinyMCE.
The error you spotted is because none of the 'standard' tags were found which would include things like includeonly, onlyinclude, noinclude, nowiki. This variable tinyMCETagList is populated from a mediawiki global variable set in a file, TinyMCE.hooks.php, in the root folder of the TinyMCE extension. This is also the file where the links are changed to point to TinyMCE if it is enabled.
Since the tags includeonly, onlyinclude, noinclude, nowiki are hard coded into the mediawiki global, the error you observe would only happen if TinyMCE.hooks.php or the file that calls it, extension.json is somehow corrupted, out of date or not getting loaded correctly.
The first step to check this, I think, is to delete or rename the current TinyMCE extension folder in your wiki. Then re-download the TinyMCE extension from here. Then unpack the 'tar' file and place the 'mediawiki-extensions-TinyMCE-master' directory folder into the '/extensions/' folder of your wiki and rename it to TinyMCE.
So this does appear to be a problem with the mediawiki load on the server side. Unfortunately the browser console only tells us about the errors on the client side!
To get some additional information about possible errors on the server side, would you add the following lines in your LocalSetting.php files at the top. That is after the '<?php' line and lines starting with a '#'.
$wgDebugToolbar = true;
$wgShowExceptionDetails = true;
error_reporting( -1 );
ini_set( 'display_errors', 1 );
If you now reload the browser window, You should see something like this at the bottom of the window.
Use of Sanitizer::escapeId was deprecated in MediaWiki 1.30. [Called from pivotTemplate::renderSidebar in www\dev.seite.de\skins\pivot\Pivot.skin.php at line 306]
Backtrace:
GlobalFunctions.php line 1029 calls MWDebug::deprecated()
Sanitizer.php line 1086 calls wfDeprecated()
Pivot.skin.php line 306 calls Sanitizer::escapeId()
Pivot.skin.php line 128 calls pivotTemplate->renderSidebar()
SkinTemplate.php line 129 calls pivotTemplate->execute()
SkinTemplate.php line 144 calls SkinTemplate->generateHTML()
OutputPage.php line 2615 calls SkinTemplate->outputPage()
MediaWiki.php line 947 calls OutputPage->output()
MediaWiki.php line 960 calls MediaWiki->{closure}()
Just a thought. In your preferences, would you disable the 'Activate the edit toolbar' option there and save. Would you then try to load the editor from a red link or other edit link? DuncanCrane (talk) 15:20, 25 November 2020 (UTC)Reply
Good morning, ehm I will unfortunately not find what I am looking for. Neither with the 1to1 translation nor if I look for similar points.
Could you give me a hint where exactly the point is to be found?
Of course. BTW you have done brilliantly with the comms. I'd really struggle doing this in a different language (except maybe if it was javascript :-) )
If you go into your personal preferences on the 'Editing' tab you have several options. The option I want you to deselect is the last under the 'Editor' heading. This has a label 'Enable the editing toolbar. This is sometimes called the "2010 wikitext editor". This option should be cleared. I tried changing my wiki language but it seems this screen is still in English. So my apologies I can't give you a localised version but hopefully this capture will make it clearer? Here is the screen which shows the item selected. Once cleared the tick in the box should be a blank instead of course.
I am stupid! I had Google set to automatically translate German to English!!
I think what may have happened is that you disabled VisualEditor and the WikiText editor in LocalSettings.php something like this:
#wfLoadExtension( 'VisualEditor' );
#wfLoadExtension( 'WikiEditor' );
I'm sorry i I gave the impression you should do this in LocalSettings.php, I meant for you to do it in the preferences screen (see below). If I am right, would you re-enable the two extensions in LocalSettings.php by removing the '#' at the start of each line? You should then see the options below in the 'Bearbeiten' tab in your preferences. If you do, would you deselect options 4 and 6 under the heading 'Bearbeitungsprogramme'?
If you then select a link to edit, would you let me know what happens?
How confident are you with making changes to code?
What I'd like you to do next is make a small and temporary change to the file TinyMCEActions.php in the root folder of the extension.
Right after the lines at line number 51, which are:
static function displayTabAndModifyAddTopicLink( $obj, &$links ) {
global $wgRequest;
global $wgTinyMCEUse;
I'd like you to insert the following lines and then save the file:
MWDebug::init();
$txt = "\nLinks in TinyMCEAction\n";
MWDebug::log($txt);
$txt = print_r($links, true);
MWDebug::log($txt);
Assuming you still have the lines to invoke debugging in your LocalSettings.php which we talked about above:
$wgDebugToolbar = true;
$wgShowExceptionDetails = true;
error_reporting( -1 );
ini_set( 'display_errors', 1 );
If you then load any page for viewing you will get two additional entries in the mediawiki debug console with the label 'log' on the left. Would you copy those and send them to me? DuncanCrane (talk) 12:07, 26 November 2020 (UTC)Reply
Sorry, I had to go out for a bit. Thanks for that.
So the good news is that the programme is running and we can dumpt stuff to the debugger. It is a bit odd though that we are getting the output twice but never mind for now.
Without removing the original change, would you now put the same fives lines just before the return statement at the end of the TinyMCEActions.php file, also adding a '1' to the 'Links' text as follows:
MWDebug::init();
$txt = "\nLinks 1 in TinyMCEAction\n";
MWDebug::log($txt);
$txt = print_r($links, true);
MWDebug::log($txt);
The return statement is something like:
return true; // always return true, in order not to stop MW's hook processing!
Would you then reload the page and send me the 'log' output displayed.
Thank you too for persevering and trying to get this to work :-)
Ok, now this is strange. The fact you get the 'Link 1' log entry shows that TinyMCE editor has passed the various tests necessary to edit a page. Also, if you look at the 'Link 1' log entry, the 'Diskussion' and 'Bearbeiten' links both have 'action=timymceedit'. When you hover over the name of these tabs on your wiki page, you should see that the link text is the same as the href here.
As this doesn't seem to be so, it must mean something else in your configuration is overriding these settings before the page is output to your browser.
This means we have to find out what is causing this by a process of elimination. Would you go to the 'special' 'version' page on your wiki and take an image of it and send it to me so I can see everything that is loaded and the versions? Sorry, it may require a few images to get everything. DuncanCrane (talk) 10:02, 27 November 2020 (UTC)Reply
hmmm that's strange. when i click on "edit" it looks like this: https://ibb.co/fprfpwh
The 'edit' you are hovering over is a 'section' edit link. This should also have a 'tinymceedit' action too but we can come back to that. The two links I'm interested in for now are the 'Discussion' and 'Edit' links in the pivot 'Actions' menu and what they show when you hover over them?
Your 'versions' page looks OK. I've disabled everything in mine so it looks like yours, but I still get the TinyMCE editor! Oh dear!!!
If you download this branch it has a number of other small bug fixes:-) These will be uploaded to the mediawiki Gerrit repository in the next maintenance release but if you'd like them straight away then please download from the development site on GitHub.
Hopefully everything is good now but do let me know if you have any more problems.
. Leaderboard (talk) 09:17, 27 January 2021 (UTC)
