Dhrup2000 wrote on 41774156-07-09

Verified the Code and the Database after creating/updating the pages Privacy, Terms, About for ExPages objects (XAMPP) -- entities' ACCESS ID are set to= "2" (Public).

Looks like ExPages access control works as intended / expected. All the three external Pages are viewable in testing here when logged out of 1.8.0.1.

cash wrote on 41774472-01-06

This is about using the site pages with the walled garden.

Three options:

• register the pages as public
• offer it as an option per page or for all pages
• change nothing and require that anyone wanting this implement through a plugin

cash wrote on 41782492-08-04

Looking for input on this

brettp wrote on 41782647-09-17

Public pages. The original purpose of the external pages plugin was to allow pages "external" to the network, so I think that's how most people expect them to work.

A long term improvement can be an offer the option on each page or all pages.

cash wrote on 41782668-09-08

I agree.

Milestone changed to Elgg 1.8.1 by cash on 41782668-09-08

trac user iionly wrote on 41784379-02-25

As Brett said, the "external" indicates that the pages are accessible also from outside the network. Especially, pages like "About", "Terms" and "Privacy" are of interest for people prior joining the site also - maybe even more so on a walled garden site where no other "sample" pages are accessible.

May I ask if the walled garden mechanism in Elgg 1.8 is based on the Elgg access level system and allows public content to be viewed by non-members also? I wonder, because "public pages" are mentioned here in the context of the walled garden mechanism. I mainly use a walled garden plugin (loginrequired) in Elgg 1.7, because the default access level set for the site can be broken by users by setting "public" as access level for their content regardless of the default access level. If the walled garden mechanism in Elgg 1.8 would not shield public content from non-members, this would make using it rather pointless. I tried to figure out how the walled garden mechanism is implemented but haven't managed it yet. I also tried to code an Elgg 1.8 version of the loginrequired plugin but it seems not as simple as I thought at first. This plugin blocks access to all pages when not logged in with the exception of urls that are included in an allowed list (index page, register and lost password pages, external pages and /_css/css.php and /_css/js.php). I guess the css.php and js.php files are now the problem that block upgrading the plugin to Elgg 1.8.

cash wrote on 41784432-07-06

https://github.com/Elgg/Elgg/blob/master/engine/classes/ElggSite.php#L391

There is a plugin hook for adding pages. And to answer your question directly, it does not use the access on content to determine what is exposed to the public. See https://github.com/Elgg/Elgg/blob/master/mod/uservalidationbyemail/start.php for an example of using the hook.

cash wrote on 41785178-07-13

Huh...not trivial at all since it requires redoing the walled garden page (which needs its html/css rewritten.

Dhrup2000 wrote on 41785639-03-10

The hook :-
elgg_register_plugin_hook_handler('public_pages', 'walled_garden', 'expages_public_pages');
-- does allow any plugin to declare 'logged-out pages'
( I posted some more code details @ http://community.elgg.org/pg/forum/topic/801224/privecy-policy/ )

Walled-garden now forces to the bare Login page (Cash's HTML/CSS point above). (I also tested walled-garden + Glossy RJC's theme and the Login block doubled there).

The approach FBFK took was to create Static HTML pages for most of Terms, Privacy, etc
and so thereby totally bypassing any access controls.

The ExPages Plugin is somewhat 'special' but 1/2-way. It's data is stored and controlled
by Elgg's security. The design 'philosophy' for ExPages maybe could do with a 're-hash' -- (1) Controlled Pages where Elgg comes into play or (2) 'UnControlled (static) Pages' outside Elgg's normal (walled) controls.

I've read thru the various code areas invoked for walled-garden and tho there's work to be done there - it is not so-o complicated. The design direction is the more important aspect to consider.

If I were to re-design / code 'ExPages' ('StaticPages'?) - I would remove the object storage for Terms, etc (as FBFK) and write to Www.Domain.Com/Terms.html and so on - no more access controls and also allows HTML savvy Elggsters the opportunity to customize as they like without the need to be involved with the internals of accesses.

trac user sembrestels wrote on 41819287-04-10

Pull requested: #81

cash wrote on 41819316-05-02

Sem - we don't close a ticket until the pull request is applied.

trac user Cash Costello wrote on 41820892-06-19

Merge pull request #81 from sembrestels/e778258e839965597e5ebb8da362806db83e0dfb

Fixes #3947 by adding site pages to the list of public pages
Changeset: bce6a70

trac user Sem wrote on 41850785-06-20

Closes #3947. External pages are now viewable by visitors in walled-garden sites. Footer menu is also added into walled-garden logging page.
Changeset: e778258

trac user Cash Costello wrote on 41850785-07-02

Merge pull request #81 from sembrestels/e778258e839965597e5ebb8da362806db83e0dfb

Fixes #3947 by adding site pages to the list of public pages
Changeset: bce6a70