Extension talk:SocialProfile

Previous discussion was archived at Extension talk:SocialProfile/Archive 8 on 2017-12-22.

Please post new topics here, with the newest posts being at the bottom of the page. Discussions are archived gradually, so please check the archives to make sure that your question hasn't been answered already!

I want to use this extension in Korean. My wiki is set in Korean, and LocalSettings.php is using UTF-8. Is there a way I can change this extension to Korean? If not, I want to know how I can translate it

Ideally, you should collaborate translating it on Translatewiki.net. They have a nice tool that helps translating groups of messages and makes it very convenient. As you can see in the commit history, every few days it gets updates from translations made in Translatewiki.net. Once translations get updated, you can download again the extension to get those translations, and other users would also benefit!

You can also translate strings locally on your wiki overriding system messages. See Help:System message.

Since this extension is split into several related extensions, each of them has their own translation group in translatewiki, keep it in mind when searching for messages.

For example, there's socialprofile userprofile, socialprofile userrelationship and others...

@멍한오리: Ciencia explained the issue pretty well above. I'd add that you should definitely join Translatewiki.net (TWN) and start contributing there; I cannot in good faith recommend maintaining a complete translation for something as big as SocialProfile on a wiki, because:

1. it's just pointless,
2. other Korean-speaking people won't be able to benefit from it (besides the users on your wiki, of course), and
3. there's a chance the translations will become outdated and it won't be so easy to spot such things, but on TWN the system automatically marks them as outdated and even shows you what changed in the source text

I'm aware of at least one wiki that uses a forked version of SocialProfile with Korean UI translations — but unfortunately instead of following these best practises, they chose to hard-code in the Korean strings altogether. :-(

This TWN link should show you all the untranslated strings in SocialProfile, for each and every sub-component (e.g. UserProfile, UserRelationship, etc.). According to the per-language translation statistics for SocialProfile, of the known 635 i18n messages, only 35 are translated to Korean — that's only 5% of the total amount! (Some other social tools are, somewhat bizarrely, more translated into Korean; looking at the statistics for the entire social tools group, currently 890 messages are translated, so 1054 remain untranslated to Korean. I'm not sure offhand which extensions are the ones that support Korean better, but I do find it fascinating that SocialProfile isn't among the better-supported ones.) One thing to note is that the statistics are ever so slightly misleading, because they also include API i18n messages, but those are virtually never shown to the end-users, so they shouldn't be a priority in any case.

For example, the Finnish (fi) translation, which I maintain, has most if not all API i18n messages untranslated; this amounts to a total of over 100 untranslated strings across all social tools and a total completion rate of "only" 93%, but this is perfectly usable in practise.

I'm more than happy to help you out with getting started, so please let me know if you need any assistance!

first thanks for all the hard work what you doing.

We have installed MediaWiki 1.40.1 everything is working exept the upload avatar from SocialProfile

Olso works other uploader for placing images to a blog stories etc olso thumbs works, exept SocialProfile upload does not work

we getting: [21b068a135179427fe87c0fa] 2023-12-06 19:27:04: Fatal exception of type "Error"

Set $wgShowExceptionDetails to true and try again. We need a more descriptive error message.

Thanks for your respons we have add $wgShowExceptionDetails to true

/index.php?title=Special:UploadAvatar

[0c434d423bdba7ce92964dd4] /index.php?title=Special:UploadAvatar Error: Call to undefined function imagecreatefrompng()

Backtrace:

from E:\HostingSpaces\Futselaa\wiki.openn.eu\wwwroot\extensions\SocialProfile\UserProfile\includes\avatar\UploadAvatarTrait.php(121)

#0 E:\HostingSpaces\Futselaa\wiki.openn.eu\wwwroot\extensions\SocialProfile\UserProfile\includes\avatar\UploadAvatarTrait.php(231): UploadAvatar->createThumbnail()

#1 E:\HostingSpaces\Futselaa\wiki.openn.eu\wwwroot\includes\specials\SpecialUpload.php(568): UploadAvatar->performUpload()

#2 E:\HostingSpaces\Futselaa\wiki.openn.eu\wwwroot\includes\specials\SpecialUpload.php(232): SpecialUpload->processUpload()

#3 E:\HostingSpaces\Futselaa\wiki.openn.eu\wwwroot\extensions\SocialProfile\UserProfile\includes\specials\SpecialUploadAvatar.php(69): SpecialUpload->execute()

#4 E:\HostingSpaces\Futselaa\wiki.openn.eu\wwwroot\includes\specialpage\SpecialPage.php(701): SpecialUploadAvatar->execute()

#5 E:\HostingSpaces\Futselaa\wiki.openn.eu\wwwroot\includes\specialpage\SpecialPageFactory.php(1475): SpecialPage->run()

#6 E:\HostingSpaces\Futselaa\wiki.openn.eu\wwwroot\includes\MediaWiki.php(327): MediaWiki\SpecialPage\SpecialPageFactory->executePath()

#7 E:\HostingSpaces\Futselaa\wiki.openn.eu\wwwroot\includes\MediaWiki.php(923): MediaWiki->performRequest()

#8 E:\HostingSpaces\Futselaa\wiki.openn.eu\wwwroot\includes\MediaWiki.php(576): MediaWiki->main()

#9 E:\HostingSpaces\Futselaa\wiki.openn.eu\wwwroot\index.php(50): MediaWiki->run()

#10 E:\HostingSpaces\Futselaa\wiki.openn.eu\wwwroot\index.php(46): wfIndexMain()

#11 {main)

imagecreatefrompng is a PHP function, available when PHP has been compiled with GD support.

It looks like you'll need to install the php-gd package and/or enable it in php.ini

Product	Version
MediaWiki	1.40.1
PHP	8.1.13 (cgi-fcgi)
ICU	70.1
MySQL	5.5.28

We have php version 8.1.13

In PHP 8.1, there’s a new lossless WebP encoding support for the GdImage object. It can be enabled using GD extension and libwebp version 0.2.0. The new PHP constant to declare the lossless WebP encoding is

IMG_WEBP_LOSSLESS

IMG_WEBP_LOSSLESS, along with

imagewebp

imagewebp function. In a PHP code, it looks like this:

Plain text

Copy to clipboard

Open code in new window

EnlighterJS 3 Syntax Highlighter

$image = imagecreatefromjpeg('image.jpg');

imagewebp($image, 'image.webp', IMG_WEBP_LOSSLESS);

$image = imagecreatefromjpeg('image.jpg'); imagewebp($image, 'image.webp', IMG_WEBP_LOSSLESS);

$image = imagecreatefromjpeg('image.jpg');
imagewebp($image, 'image.webp', IMG_WEBP_LOSSLESS);

So, how can it work with upload avatar? If we do a normal upload the Thumbs are vissable and uploading works. Only not for the avatar on the SocialProfile. And we use the latest version from your SocialProfile.

Wiki uploads use imagemagick for thumbnailing. SocialProfile, however, does not and uses PHP GD instead. That may be a reason of why wiki uploads work without errors but avatars don't.

See Manual:Php.ini, create a file in your webserver to display the php information as described on that page, and see if gd is listed as a loaded PHP extension module. Install or enable it and try again until it's listed as enabled.

thats not possible , i use a webhosting , other way? Maby a alternative plugin extension for the upload possible to direct upload for the image/avatar map ?

So what the sollution ?

Ask your hosting provider to enable GD. Or get a better hosting provider.

becourse everything works ecept your extension for upload you gonna advise change hosting ?

problem solved we are back on the version php and now works.

https://github.com/wikimedia/mediawiki-extensions-SocialProfile/blob/24ac6d2c43acdd82bc7e09351651b7f6d435fe84/UserProfile/resources/css/UserProfile.css#L1

So the rules doesn't work for Timeless, it couldn't properly hide the first heading of Timeless; when tagline is manually enabled through CSS it collides with the first heading.

First off, the mandatory disclaimer: only the latest LTS release (1.39) is truly tested and supported, support for any and all other versions is coincidental at best. :-)

Now...

This looks like it might've been caused by commit e733d2624a03eb05c19240e6302939a2c288dbfb on the Timeless repository, which for sure overrides the .firstHeading rule from SocialProfile's /extensions/SocialProfile/UserProfile/resources/css/UserProfile.css. Maybe something like .skin-timeless h1.firstHeading, in addition to the existing .firstHeading rule in that file, would do the trick? Let me know and I'll be happy to amend the file accordingly. (Although I'm not fond of skin-specific hacks, I'm hoping that there won't be too many such similar cases; but as of MW 1.39 pretty much all skins, even Timeless, behave as expected, so...hard to tell, really.)

@Jack Phoenix Welp, as long as you could manage to manage the whole project structure more stable and easy to maintain, a fix on your side would be preferred. For now I'm using a pretty bad way to detect whether the user profile ResourceLoader module is loaded and then load a fix style accordingly if yes, and I must say that I'm not satisfied with this https://lakeus.xyz/wiki/MediaWiki:Gadget-userprofile-fix.js. I must say though, why not just add an !important to display: none ? There are already some of these for some unknown reason to me anyway.

Patch was merged, issue is now resolved

In UserProfileHooks.php, the function onDifferenceEngineOldHeader() and onDifferenceEngineNewHeader(), the $oldHeader and $newHeader construct the header with <h4> instead of <strong> (MediaWiki default behavior), causing RevisionSlider fails to select the element.

Thanks for the very useful bug report and research! :) I've submitted a patch based on the information provided to gerrit; give it a spin and let me know if it fixes the issue and I'll be happy to +2 the patch and have it land on master to fix the issue for all users.

That's exactly what I've done to my installation. It works.

Hi sir, I installed this extension as procedure said,put require_once "$IP/extensions/SocialProfile/SocialProfile.php"; into localsetting.php,and then run update.php,but it doesn't work when i open special:version.

I am confused ,it seems only me have this problem.

BTW,is it conflict with semanticMW,because each time I will run rebuildData.php in SMW/mainteinence after update.php done.

My MW version is 1.39.3,and SMW is 4.1.1

Or maybe I should set $wgUploadDirectory?I didn't add this code in localsetting.php.

Can anyone help me ,i am a greenfinger about this mediawiki and try to learn about this.Thank you very much at all.

What does this mean? "but it doesn't work when i open special:version"

Do you get an error? Or does it not list the extension?

Hi Ciencia Al Poder

sry for my expression，I mean it didn't install into the MW，and I have re-install my mediawiki ，and then succeed to install this extension，wired，maybe the database problem i guess？ Thank you for your reply.

When I use the master version, everything works fine.

I have installed SocialProfile on my MediaWiki 1.39 instance. When I click on the "Use Social Profile User Page" button on my user page (which is currently a wiki user page), nothing happens. Then, when I click on the "Yes" button on the "Special:ToggleUserPage" page, it throws an error: "Error: Call to undefined method Title::getContext()".

SocialProfile.php (from 104):

// Prefix SocialProfile will use to store avatars

// for global avatars on a wikifarm or groups of wikis,

// set this to something static.

$wgAvatarKey = $wgDBname;

but, RandomUsersWithAvatars.php (from 47):

if ( !$data ) {

$files = glob( $wgUploadDirectory . "/avatars/{$wgDBname}_*_{$size}.*" );

(72): preg_match( "/{$wgDBname}_(.*)_/i", $avatarName, $matches );

Thanks for the report, this is now fixed!

If you're curious about the history: the $wgAvatarKey patch in SocialProfile (commit bbb405a0a208a915c0f746b4c501ab6a8d9d86c9) took place years before phab:T195173 was resolved; because RandomUsersWithAvatars was, at the time, a separate extension, nobody thought of updating it. Oops. :) Glad you caught the bug now and reported it!

Issue fixed by patchset 97b429039441994e06cdf3bf72032137af036963

after saving the text in custom fields, all fields have the same text

SpecialUpdateProfile.php: from 913: ( isset( $custom2 ) && $custom2 ? htmlspecialchars( $custom1, ENT_QUOTES ) : ) ( isset( $custom3 ) && $custom3 ? htmlspecialchars( $custom1, ENT_QUOTES ) : ) ( isset( $custom4 ) && $custom4 ? htmlspecialchars( $custom1, ENT_QUOTES ) : )

everything okay?

and here 776: ( isset( $snacks ) ? htmlspecialchars( $tv, ENT_QUOTES ) : )

Thanks for the report, now fixed! 👍

mw_1.38 && (sp_1.38 || sp_master) if i want to create a page in the user namespace eg user:user\newpage get exception MediaWiki internal error.

Original exception: [7ed5ff5d67faf0f3f8fe2f13] /page/User:Root/dsf Error: Call to a member function getName() on bool Backtrace: from \w\extensions\SocialProfile\UserProfile\includes\UserProfile.php(85)

1. 0 \w\extensions\SocialProfile\UserProfile\includes\UserProfileHooks.php(118): UserProfile->__construct()
2. 1 \w\includes\HookContainer\HookContainer.php(338): UserProfileHooks::onArticleFromTitle()
3. 2 \w\includes\HookContainer\HookContainer.php(137): MediaWiki\HookContainer\HookContainer->callLegacyHook()

...

lines from 117 in UserProfileHooks.php: if ( $wgUserPageChoice ) { $profile = new UserProfile( $pageTitle ); $profile_data = $profile->getProfile();

i can catch the exception and redirect to main page, but is not good solution

Looks like the same as phab:T325830

I added: $wgNamespacesWithSubpages = [ NS_MAIN => true, NS_USER => true ]; And cutback my exception catch ) It works. Add this to description page.

MediaWiki 1.38 isn't a Long-Term Support (LTS) release of MediaWiki anyway so it hasn't ever been tested and any and all support for it has been and remains coincidental at best; refer to social tools/MediaWiki compatibility, but basically always use master version of SocialProfile and other social tools with the latest LTS release of MediaWiki, that's something that's actually tested and supported.

pf) I have no doubt that all the same would be in 1.39 )

Greetings. The extension has been successfully uploaded, but when I try to upload a pfp, it gives me an error. /avatars belongs to apache and is within the images directory. The only other extensions I have (apart from prepackaged extensions) are WikiForum and SkinPerPage.