Hi Jackson,
Discussion can be configured during page creation/edit(http://take.ms/UIbzM).
Polls and files can be set at the ACL setting for the page category(http://take.ms/ImmzH).
Feeds can only be set in the applications section(http://take.ms/pVA8G).

Hi Raymond,

That is strange, I don't have the discussion setting: https://screencast.com/t/ZXCDNtGh

Update: I got it, the settings for discussion is a custom field that has to be added.

Questions:

• Polls and Files, what's the implication if these settings are added to Page Edit? Why does it have to be global?
  
• Feeds, same question, why does the ACL or On/Off have to be set in the Applications global settings?
  

Suggestion: Since on/off setting can be made custom fields, why not just add the same custom fields for Polls, Files, and Feeds?

Thanks,

Jackson

Hey Jackson,
Glad to know you managed to add the discussion setting.
Some of these apps are built into the system or the cluster itself, whereas some are dedicated apps that are not built into the cluster. This is the reason why some apps may disabled/configured in different areas.
If you really want to, perhaps you can create a feature request for these fields to be added in the feature request section.

Hi Raymond,

So I dig dipper into how the Pages apps were created and found out that there might not be any conflict if Applications available to Pages are turned off. It does not make sense if it does, but can you confirm that with your developers please?

I also tried to create a custom fields in Pages to turn off Files by following how Announcements was done. It works perfectly fine! I can now turn on/off Files applications in a Page. There is one problem though, the applications code are not coded the same when checking if the app is to be listed in the page. I have to modify the Files apps under media to check for that settings. That setting is coded in the Announcements app but not in Files or any other applications that has no On/Off custom fields. If coded the same, I or anyone should be able to just create their own custom fields if they want to without being overridden on update.

I hope, it will be fixed in the future release. Here's that code that I am talking about:

/media/com_easysocial/apps/page/files/files.php

on method appListing() the original code is:

        public function appListing($view, $id, $type)

	{

		$page = ES::page($id);



		// Determines if this page has access to files

		$access = $page->getAccess();

		

		if (!$access->get('files.enabled', true)) {

			return false;

		}



		if (!$page->isMember()) {

			return false;

		}



		return true;

	}

Modify it to:

	public function appListing($view, $id, $type)

	{

		$page = ES::page($id);



		// Determines if this page has access to files

		$access = $page->getAccess();



		if (!$access->get('files.enabled', true)) {

			return false;

		}



		$registry = $page->getParams();

		

		if (!$registry->get('files', true)) {

			return false;

		}



                if (!$page->isMember()) {

			return false;

		}



		return true;

	}

Can you confirm from your developers if adding a check for page parameters affects any other functionalities of any Page apps?

Thanks,

Jackson

Hey Jackson,

Can you confirm from your developers if adding a check for page parameters affects any other functionalities of any Page apps?

I have confirmed this and the parameter check should not affect other apps because this basically just checks the parameter from the page data in the database. If you have the parameter like in the screenshot for your page, then it should be correct(http://take.ms/Bmmfe).
The reason the parameter check is not included in the media files is because there are no custom fields for those apps. It doesn't make sense to add something that does not exist yet for the convenience of 'possible' customization. That being said, without guarantee, this may be considered in the future.

Hi Raymond,
Thanks for confirming that there will be no conflict.

It doesn't make sense to add something that does not exist yet for the convenience of 'possible' customization.

Thoughts:
Please let Mark know about this. It's not about "customization" I am about logic, you guys provided an option in ES to install Applications. Logically speaking, you are opening ES for developers who would want to extend ES default functionalities, right? Unless, the design was only StackIdeas developers should be able to create Applications, then for me, logically, what you said "It doesn't make sense to add something that does not exists yet..." applies. It was you guys who thought not to create a custom fields to turn on/off the files and of course, it is just logical that checking for that parameters should never exists. But! since there is an option to install custom applications, by the your client, then it means you are opening it for possible options.

I am not asking for something that you guys have to change things for my "convenience of possible customization". I am asking and actually pointing out something that you guys should think about. Also, the reason why I am asking if there's any possibility of conflict in the code change. I am not pushing, I am suggesting and pointing another perspective to the feature of being able to install/create own applications.

The reason the parameter check is not included in the media files is because there are no custom fields for those apps.

Thoughts:
Since you said, there should be no effect to other apps, based on my statement above, logically, shouldn't we open it to a possibility that someone might create a custom fields that would check for this parameter and we should make it available?

We're using Joomla!, and it provides override on most things possible without breaking core functionalities. That is where I am coming from and I am glad you guys created producst that takes that into the next level.

Thanks,

Jackson

Thanks for your input on this Jackson. To be honest with you, this was our intended goals including the ability to add / install apps on the platform per user basis.

However, based on our past 2 years experience with users running a social site, this capability is too overwhelming for 90% of these customers. Generally most of them would just want a global settings that could be turned on or off.

The more complexity we add in setting things up, the harder it is for users to adapt to EasySocial. At the same time, we also need it to be extensible so users like yourself, would be able to enhance the platform. It's almost like a catch-22 situation.

Hi Mark,

Thank you for personally answering my thoughts.

I understanding where you are and how things has been changing from the original ES, I was one of your first clients who used ES. I was also involved with it during the beta stage. The original ES design in my opinion empower developers alike to be able to create options for themselves based on their taste and needs. Not until the release of v2.x when you guys decided to cater to your "clients" who uses or want to use software with default functionalities or more so, have simple settings.

Personally, when I was looking for Joomla extension for profiles, I first found JoomSocial. I actually find it to be simple and easy to use, pretty much all you need to do is to install it and use with all the defaults and you should be good to go. After testing it extensively for months, I ditched the project since Jomsocial (older version that I last know) was not designed to handle community privacy. It was designed, in my opinion, it seems that they think everybody in the community should see everything.

With the advent of EasySocial, having securities by design, custom fields with privacy is the reason why we are using it as our profile engine. To top it all up, it was designed to enable developers to create custom and unique social media engine that will fit their needs, tailor EasySocial according to their client needs. Unfortunately, now you seems to be giving up on that, you are going to a route to create a lean and one setting kind of product just because you said 90% of clients are confused with settings.

Like, I said, I am coming from the perspective of a Joomla user. If Joomla developer's goal is to make Joomla easy to understand, easy to use, and will not confuse those "simple users" they would have simplified everything and removed distinction of modules, components, and plugin and simply call them plugins just like Wordpress. But they did not, they maintained distinction and structure, each names were designed and named according to how it function logically. Well, that was the confusion I oftentimes hear from friends that are Wordpress users who tried to use Joomla.

Imagine Facebook, if they have decided to simplified their platform to avoid confusion so more people will use it. They rather made more security settings (privacy) but simplified it and made if more friendly and easy to understand. If you ask me as a webadmin, not a developer, software settings is meant to be confusing and that is why there are so called technical manual or documentation . Webadmins are ought to read manuals and understand how components work and not complaint about how complicated a component is, isnt't it? LOL!

I guess, I am just trying to convince you to maintain your original ES design and not give in to clients complaints of confusion . But then again, it is business for you and I understand.

Thanks,

Jackson

Hello Jackson,

I appreciate your insights on this and to be honest, without suggestions and feedback from you guys, we would have never made it this far so yes, I am always listening

Our goal is to not make it less extensible or customizable but rather it needs to be extensible in a different manner. One very good example you have provided is the settings.

If we have added settings for every single button, strings or even actions, nobody would understand this except some good developers or webmasters. Not only bloating the settings is an unfriendly approach, it adds more overhead to the system.

We then re-thought the whole user experience over and over again. If people like yourself who are more experienced developers, should be able to customize this simply by using template overrides. This approach makes more sense for the software and developers like yourself because you would be able to bill your client for the work that you have done

Moving forward, we do intend to simplify the user experience but that doesn't mean that it is less extensible

Hi Mark,

Thanks if that's the case I hope extensibility would not suffer in exchange of simplified experience.

Anyways, going back to my original post where I pointed out how an app is not checking a certain variable. Don't you think it justify a code change so extensibility will work?

Thanks,

Jackson

Thanks for your suggestion, i will bring this up to our team regarding this matter and we will see if we can find a better way to address this in the future.