1 - Every time after these changes you must clear the cache.

2 - Perhaps, some plugins have the same view.

3 - You can try to unextend this view in your custom plugin:

elgg_unextend_view('forms/attachments/upload', 'input/attachments');

4 - If you make this change in your custom plugin, make sure it's moved after the original plugin by priority.

Learn more methods.

Thank you RvR. 

I did all your suggestions but it still does not work.

Perhaps, some plugins have the same view.

I do not think there is other same view since when I comment the whole input/attachments.php its content disappears from the page (as desired).

The mystery is what causes this view to appear. 

Generally speaking I prefer replacing (not just overwriting) the vendor folder and the Elgg core bundled plugin folders in the mod directory plus checking for differences in the files elgg-config/settings.php and and .htaccess that might need to be resolved. In case of an update from 2.3.10 to 2.3.11 a comparison showed that there are no files in 2.3.10 that are no longer there in 2.3.11, only a few new files in 2.3.11 and then only changed files. So, when updating from 2.3.10 to 2.3.11 you could just overwrite the mod and vendor folders and overwrite composer.json and composer.lock files in the main folder and it should be alright. Nonetheless, a backup of the database should always be made first before upgrading (and making a backup of the install folder and data directory regularly is a good idea, too). After overwriting the files you would run upgrade.php (or clicking on the Upgrade button in the admin area) and you should be done.

http://learn.elgg.org/en/2.3/admin/upgrading.html

Very helpful.

Thank you very much

Thank you iionly.

After I change the error_reporting setting the reported error will disappear, but the error will continue to be there. Does the error not affect the functioning of the system?

The log entries are not errors but only warnings. The code works as it is even if it is not strictly standard conform. It might be that on a later PHP version the situation changes and the code might have to be modified but as long as you don't upgrade to a newer PHP version it's not a show stopper (and even on a new PHP version it might still work without changes). That's what the warning is trying to tell you.

I understand.

Thank you very much

elgg_register_menu_item('topbar', array(
 'name' => 'menu',
 'parent_name' => 'account',
 'href' => "action/menu",
 'text' => elgg_echo('menu'),
 'is_action' => true,
 'section' => 'alt',
));

Thank you Rohit Gupta.

I did it, and the "menu" item appears under "account". However, I need the whole "site" menu to move there i.e. 

• Activity
• Blogs
• Bookmarks
• Discussions
• More
• etc

and then, remove the "site" menu from its original location.

I mean - move the whole "site" menu in one stroke - not item by item.

As @RVR said Elgg saves an entity icon in .JPG format always, and JPG does not support transparent background.

However, the fact is that with GD php extension, Elgg retain the transparency of PNG even though the image file name has JPG suffix. The reason for this is that Elgg does not transform PNG to JPG. It just replaces the suffixes, i.e PNG -> JPG. I checked this phenomena (replacing the suffixes) outside Elgg's environment and found the same. The browsers (Chrome, FF and IE) retain the transparency and animation of PNG and GIF, even though the suffix of the files is JPG.

@iionly said:

Tidypics keeps the image format unchanged when resizing/creating the thumbnails and it uses the Imagick php extension directly

Now we know that Elgg also keeps the format unchanged (changes only the suffix - which is not the best practice IMHO). I believe it is possible to build a plugin that replicates the functionality of Tidypics, and handle all the images of Elgg through Imagick php extension directly. In this way the problem with the PNG transparency will be solved. 

Could someone suggest how to do it?

Thank you very much.

I think it wouldn't be that easy to write such a plugin. The point is: Elgg core makes use of the Imagine library to use the same set of API functions regardless if GD or Imagick php are used. Imagine "translates" the functions accordingly. Also, Elgg most likely currently expects that the images (profile images, entity icons and file thumbnails) have the jpg suffix regardless what file type the files really are. If the png files would now suddenly saved with png extensions they would probably not getting served.

The problem with the image file creation could probably be solved by replacing all Elgg core actions with modified versions that use their own set of image resizing functions (like Tidypics does). Probably the output file type issue could also be fixed somehow - but don't ask me for any details as I wouldn't have them right now.

The question is if it couldn't be solved by improving the Imagick plugin and/or using a newer version of the Imagine library as Elgg core currently does. These questions might be best answered by the Coldtrick guys as they might know best. Unfortunately, I can't provide any more help currently just due to lack of detailed knowledge.

Unfortunately, the new version of Imagine does not solve the problem.

Anyway, thank you very much.