The comments extension doesn't create the table Comments.
Extension talk:BlogPage/Flow
Mostly a cosmetic thing, but the blogpage would look a lot better of the links were formatted correctly
- different sizes of the same page
Full Blog post zoomed out. Notice the "Dont miss" and "New Articles" blog links all the way at the bottom right
notice the large space under "More by Kofi" where the "dont miss" and "new articles" should be
Notice the "Dont miss" and "New Articles" blog links all the way at the bottom right
This is a known & tracked issue (see phabricator:T153522) but nobody's actively working on it. (Patches welcome!)
The underlying issue here is that on the wiki where these tools were developed (ArmchairGM) over a decade ago, they were geared to work with the site's default/recommended skin and thus any and all other skins were simply not tested and were not a concern to the developers, as users were simply assumed to use the default skin. That skin is no more, and nobody has really revamped the BlogPage layout to better support modern skins like MonoBook or Timeless.
the example on page http://social-tools.wmflabs.org/ is out of order
Yes, this is known. I should bring that back up and update the site, but it's not a high-priority task. (If you'd like to help with this or know someone who would, please file a ticket on Phabricator!)
This is the line that I could not correctly generate when translating into another language
To call the API, use <tvar|action><code>action=''blogpage''</code></>, along with appending the parameters.
I do not know, if I have put the data wrong when translating (into Spanish) or any option is missing in the original language, thank you.
The BlogPage API module was deleted in March 2020 as it had been obsoleted by a core MediaWiki API.
I have a 1.18 wiki with the SocialProfile and all of its components installed and working fine, but when I installed BlogPage and added the require_once line, the site went blank.
What did I do wrong?
Thanks, Asaf
MediaWiki 1.18.1
PHP 5.2.9 (apache)
MySQL 5.0.67-log
94.159.139.150 10:45, 2 March 2012 (UTC)
Try upgrading PHP, and using the appropriate version. Likely you have a syntax error in your configuration file or you did not get the right version.
Thanks, it works!
Asaf
Need help, cannot create any blog entry due to 'There's already a blog post with that title. Please choose a different title for your blog post.' Any entered title reports above error without creating anything. Mediawiki: 1.18.1 PHP: 5.3.2-1 Latest Extensions: Comments, VoteNY, SocialProfile
The blog extension has installed correctly, however, I'm getting JS errors whenever I'm trying to create a blog.
Throws CreateBlogPost is not defined. Did I miss a step?
It's not loading the JS at all using the $wgResourceModule, we are using 1.17.
Your problem is MediaWiki 1.17; its ResourceLoader is buggy. I'd suggest upgrading to MediaWiki 1.18 when it's out (but 1.18 beta 1 is already out).
I got the ResourceLoader working, but now I have found a new bug. Whenever I submit a blog, I get an error from BlogHooks.php. On line 138, there is only two variables being passed in the preprocessor which is throwing an error from parser.php line 447. Any fix?
To be more precise it's on the ctgTitle = Title::newFromText
I'm using the latest revision of all the dependency plugins as well.
Thanks for the bug report, I've fixed that bug in r102094.
You are welcome Jack!
Don't work 1.16.5
Thank you for this detailed bug report. Could you be any more specific about it?
blank main page
That is still as unhelpful as your initial message. I suggest you take a look at Manual:How to debug and come back with some detailed information. A blank main page could be caused by a fatal error, a syntax error or anything inbetween.
Could someone who is using this post the URL of their blog?
wow, this is 9 years. But I have the same question! It would be nice to see what it actually looks like!
Greetings.
So I've recently upgraded my mediawiki and have been overhauling a lof of the backend.
When trying to get the social extentions up again everything looks good until I do one of two things
1: if I load the extensions that I use-
wfLoadExtension( 'BlogPage' );
wfLoadExtension( 'Comments' );
wfLoadExtension( 'VoteNY' );
and I try to look at any of the blogs I previously made I get the following error:
Database error (page title)
A database query error has occurred. This may indicate a bug in the software.
[f655cda325d32fdaad3b57a0] /afropedia/Blog:Life_on_The_Open-Air_Plantation_Aint_Equal Wikimedia\Rdbms\DBQueryError from line 1603 of /var/www/worldafropedia/wiki/includes/libs/rdbms/database/Database.php: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading?
Query: SELECT Comment_Username,Comment_IP,Comment_Text,Comment_Date,Comment_Date AS timestamp,Comment_user_id,CommentID,Comment_Parent_ID,vote1.Comment_Vote_Score AS current_vote,SUM(vote2.Comment_Vote_Score) AS comment_score,stats_total_points FROM `user_stats` LEFT JOIN `Comments` ON ((Comment_user_id = stats_user_id)) LEFT JOIN `Comments_Vote` `vote1` ON ((vote1.Comment_Vote_ID = CommentID) AND vote1.Comment_Vote_Username = 'Kofi') LEFT JOIN `Comments_Vote` `vote2` ON ((vote2.Comment_Vote_ID = CommentID)) WHERE Comment_Page_ID = '19004' GROUP BY CommentID
Function: CommentsPage::getComments
Error: 1054 Unknown column 'stats_user_id' in 'on clause' (localhost)
If I try to make a new blog post I get:
[013afee92b964d8e9669368f] /afropedia/Special:CreateBlogPost TypeError from line 142 of /var/www/worldafropedia/wiki/includes/page/WikiPage.php: Argument 1 passed to WikiPage::factory() must be an instance of Title, null given, called in /var/www/worldafropedia/wiki/extensions/BlogPage/includes/specials/SpecialCreateBlogPost.php on line 105
Backtrace:
2: if I disable everything except BlogPage:
and I try to look at any of the blogs I previously made, I the load.
If I try to make a new blog post I get:
[ba6d8b074deed09cf90d9a9a] /afropedia/Special:CreateBlogPost TypeError from line 142 of /var/www/worldafropedia/wiki/includes/page/WikiPage.php: Argument 1 passed to WikiPage::factory() must be an instance of Title, null given, called in /var/www/worldafropedia/wiki/extensions/BlogPage/includes/specials/SpecialCreateBlogPost.php on line 105
This is related to the recent changes related to actor support in all social tools. The correct solution here is to upgrade your copy of SocialProfile (and/or any and all other social tools you have, e.g. BlogPage, Comments, VoteNY), to the latest (master) version and rerun maintenance/update.php, the MediaWiki core updater script, after doing that. Note that:
- you may want to make a backup of your database prior to doing this, just in case, for there are some scary internal changes
- currently social tools support only MediaWiki 1.34; older versions of MW are considered unsupported and newer ones may or may not work (but it doesn't matter because MW 1.35 hasn't been released yet)
Thanks for your reply. I uploaded the new extensions and ran the maintenance/update.php and the same errors are there.
I can only *see* old blog posts if I disable every social extension but BlogPage, and I can't post a new blog entry under any circumstances.
___________________________________
EDIT: Actually, I realized I didn't download the master files, so I just did that, reuploaded, ran php update.php and got the following:
...user_system_messages table already exists.
...user_points_weekly table already exists.
...user_points_monthly table already exists.
...user_points_archive table already exists.
...user_stats table does not contain stats_year_id field.
...user_profile table does not contain up_last_seen field.
...Comments table already exists.
...Comments_Vote table already exists.
...Comments_block table already exists.
Adding Comment_actor field to table Comments ...done.
Adding index wiki_actor to table Comments ...done.
Running /var/www/worldafropedia/wiki/extensions/Comments/includes/../sql/../maintenance/migrateOldCommentsUserColumnsToActor.php...
done.
Table Comments contains Comment_user_id field. Dropping ...done.
Table Comments contains Comment_Username field. Dropping ...done.
...wiki_user_id key doesn't exist.
...wiki_user_name key doesn't exist.
Adding cb_actor field to table Comments_block ...done.
Adding cb_actor_blocked field to table Comments_block ...done.
Adding index cb_actor to table Comments_block ...done.
Running /var/www/worldafropedia/wiki/extensions/Comments/includes/../sql/../maintenance/migrateOldCommentsBlockUserColumnsToActor.php...
done.
Table Comments_block contains cb_user_id field. Dropping ...done.
Table Comments_block contains cb_user_name field. Dropping ...done.
Table Comments_block contains cb_user_id_blocked field. Dropping ...done.
Table Comments_block contains cb_user_name_blocked field. Dropping ...done.
...cb_user_id key doesn't exist.
Adding Comment_Vote_actor field to table Comments_Vote ...done.
Adding index Comments_Vote_actor_index to table Comments_Vote ...Wikimedia\Rdbms\DBQueryError from line 1603 of /var/www/worldafropedia/wiki/includes/libs/rdbms/database/Database.php: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading?
Query: CREATE UNIQUE INDEX Comments_Vote_actor_index ON `Comments_Vote` (Comment_Vote_ID,Comment_Vote_actor)
Function: Wikimedia\Rdbms\Database::sourceFile( /var/www/worldafropedia/wiki/extensions/Comments/includes/../sql/patches/actor/add-Comment_Vote_unique_actor_index.sql )
Error: 1062 Duplicate entry '1-0' for key 'Comments_Vote_actor_index' (localhost)
after disabling comments, I ran the updater again and there were no errors.
Still same same inability to create new blog posts though
EDIT2:
After deleting the extensions and downloading the master versions and installing them again, everything worked save for creating a new blog entry. The error involved VOTENY, so I downloaded the 1.34 stable version (1a78517 of the VoteNY extension for MediaWiki REL1_34 )
After that, almost everything is good.
One small problem though, my old blog entries dont say who created them.
at the top, they simply say by created 14:50, March 2, 2019 , last edited 21:54, March 2, 2019
whereas the new blog post I just made say:
by Vapblack created 16:05, February 1, 2020
thanks for the help
Well, using the release branches (instead of master) of the social tools extensions is simply not supported, so you're on your own in that regard, I'm afraid. The existence of those branches is problematic because they are created automatically by the people handling MediaWiki releases, but I don't maintain them, so they are guaranteed to be outdated literally 100% of the time, so it's pure luck if they work or not.
Anyway, back to the original issue...
Seems like you've managed to find a tricky and annoying bug with the actor migration scripts: the Comments' migration scripts (and same for other social tools extensions, I'm afraid) don't handle a particular edge case at all. In this case, the edge case is "(anonymous) user has posted a comment (or comments) but has not performed any other actions on the wiki". The migration scripts incorrectly assume that there is a corresponding entry for every user in the actor table; but in this edge case, this isn't necessarily the case. The scripts should be able to identify these cases and create actor entries when those entries don't yet exist, but currently that is unfortunately not the case. I can't promise you a definitive ETA, but I'm hoping to get this fixed during March 2020 if not sooner.
HI,
it seems as though commenting is broken on the blog posts. nothing is happening when user clicks the button to post the comment.
The commenting functionality is provided by Extension:Comments. Regardless, the social tools are currently undergoing pretty major architectural changes to support the new actor table and the general concept of actors. See phab:T227345 for more technical details.
The issue you're describing sounds like a JavaScript error of some kind. I haven't seen any such JS errors in my devboxes. Is your wiki public so I could take a look at it?
Regardless, I suggest checking back by, say, the end of January or so; I hope the actor migration stuff has been mostly done by that point. (But if you'll look at the mentioned Phabricator ticket, you'll see that Comments and SocialProfile are some of the trickiest extensions to port over. Regardless, using actor IDs instead of traditional user ID/user name combos provides benefits like eventually being able to support user renaming on ShoutWiki, hence why that is being done now.) At that point all the social tools should support actors and work on MediaWiki 1.34 as expected.
Hi Jack,
my wiki is here https://www.G1pedia.com having the same issue with the post comment button on mobile also. when using Extension:Comments
Kind Regards
Excuse my wiki its a mess at the moment as I am trying to figure out how to add a top ten language circle.
No worries. So, looking at https://g1pedia.com/index.php/Special:Version, seems that you have the MobileFrontend extension (and its companion, the MinervaNeue skin) installed; it's a popular solution for providing a mobile experience of sorts, and was developed and is also maintained by the Wikimedia Foundation. While both the MobileFrontend extension and the MinervaNeue skin are thus quite stable, they do some things which at least I consider odd. Namely that extensions' CSS and JS ResourceLoader modules aren't loaded unless they are explicitly marked as "OK for mobile", i.e. the module definition has a targets array which specifies mobile (and optionally also desktop) as a valid target. Comments' both RL modules do specify both targets (in the extension.json file), so I'm not sure what's going on there.
BlogPage's RL modules don't specify targets, which probably in practise means with that the MobileFrontend view (which you can activate by appending ?mobileaction=toggle_view_mobile to the page URL) BlogPage's special pages look funky and don't quite work right as the CSS and JS isn't loaded. Commenting shouldn't be affected as BlogPage literally uses Comments for that instead of doing anything related to commenting on its own.
That being said, I can safely say that I've really not tested the MobileFrontend+MinervaNeue+social tools combo, so in that respect, all bets are off. Furthermore as none of the social tools are used on Wikimedia Foundation wikis, it means that WMF developers most likely haven't tested the combination either.
Seeing that you have the awesome, responsive, actively developed Timeless skin already installed, I'd consider whether you have a pressing need for MobileFrontend and MinervaNeue and the features they provide. If you choose to uninstall those two and set Timeless as the default skin, it should provide a similar-ish mobile experience without the usual MobileFrontend-specific content transformations and the like.
You can also try contacting the maintainers of MobileFrontend and MinervaNeue, Wikimedia Foundation's Reading Web team and specifically Jon Robson, to see what they have to say about this.
To clarify my stance on this: this certainly sounds like a software bug of sorts and something that'd be nice to get fixed. But I can't promise an ETA of any kind on a fix, as I don't quite fully understand what's going on here (code-wise) nor do I have time to work on this right now; the aforementioned actor migration stuff is honestly a nightmare and a time-consuming one, so I fully expect that to keep me busy at least for the next couple weeks or so.
Many thanks for your reply. Do we know what framework is used to make it mobile friendly for example (bootstrap)? its not bootstrap but it would be handy to know what language the button is written in as to why its not translated and functioning on mobile view. I am not sure if you have seen how its working but other than the post buttons not being translated. It is ready to work and looks awesome.
Use MobileFrontend if you want to serve different experiences to mobile and desktop users and optimise the experience.
Using MobileFrontend you'll have a more performant, controllable and in some cases more usable mobile experience.
The downside is many extensions are not compatible with MobileFrontend. The targets system was written intentionally to avoid the running of code that hadn't been integrated with the extension. This avoids loading code that's not needed in the given context or hasn't been tested in the existing device.
ResourceLoader/Writing a MobileFrontend friendly ResourceLoader module is pretty thorough on the why and the how extension owners can integrate with MobileFrontend.
In this case it's not a Wikimedia extension so you could probably turn on all the modules it uses with a mobile target but I cant promise the experience will be completely usable.
Note Minerva has nothing to do with this. It's just a skin like Monobook, Timeless and Vector.
thanks I've noticed a few issues with social tools I.e sending messages board to board the send button is broken. It looked like a php html issue to me this function was only broken on the mobile app. Is it possible to add flow to the user board namespace at present? Exciting stuff!
Kind Regards
There's no such support for integrating with Flow, alas. The closest related ticket on Phabricator is phab:T167312 which is about integrating SocialProfile avatars with Flow; feel free to submit a new task on Phabricator! (That being said, full disclaimer: I don't know how likely it'd be for such a ticket to get fixed at least in a reasonable timeframe. As per its own infopage here, Flow's been in maintenance mode since 2015 and I haven't looked at how complicated it would be to have user boards or other similar textareas use Flow. At least Comments is finally getting a preview feature; long overdue, but better late than never.)
Do you know of any information, I can study you would recommend please. I have a long flight coming up soon this month. And I would like to get a thorough understanding of how the scripts and extensions are working together.