Okay--got rid of the error. Still, I cannot shut down public access. Here is what I have:

 

<?php

 

function nopublic_init() {

 

// Extend system CSS with our own styles

 

extend_view('css','nopublic/css');

 

// Replace the default index page

register_plugin_hook('get_write_access_array','system','new_get_write_access_array');

 }

 

function new_get_write_access_array() {

 

    if (!@include_once(dirname(dirname(__FILE__))) . "/nopublic/access.php") return false;

   return true;

}

 

// Make sure the plugin has been registered

register_elgg_event_handler('init','system','nopublic_init');

?>

I have tried various hooks:

• access_array
• get_access_array
• get_write_access_array
• get_access_list

I edited the core access.php to test the changes I made there and all is good.

My problem is certainly in the start.php

Honestly I would just say to delete out the public access options in access.php as you did. and then just leave it be. The hack is only 1 line [you don't even need to edit out  define('ACCESS_PUBLIC',2); ]

I don't know what is wrong with your start.php file because I have not dealt with hooks a lot yet, but overall, I think as long as you remember to document some kind of upgrade checklist and put a reference to your one small edit in it, it should be fine no?  I know you probably want to contribute it to others, but it just seems like such a long way around to me.

Hope this helps (probably does not)

P.s. thanks for the writeup , I just want to attract more devs and testers! I've got some people contributing at least.

Thanks

You may be right. It is certainly simple enough to delete the code in the core. 

However, learning to do this in such a simple instance would give me the key to doing it in other circumstances. The added benefit is that once I figure it out, I'll write up a procedure in clear terms on my blog so that others can do the same. The thrust of my blog is to provide a bridge for those less adept at code. To a large extent, I think I have opened  a lot of doors for many people and would like to continue to do the same.

I also would like a nice tidy package to offer educators at an upcoming conference where I am presenting on Open Source alternatives to "free" hosted solutions for Web 2.0 applications in education.

Thanks Jade!

Steve

Still looking for any guidance on the access.php override's start.php.

I'm missing something!

Thanks,

Steve

Hello Steve, i'm trying to override /engine/lib/access.php too.

I have made a "friends only" access level directly in the core. I would like to make a plugin in order to be able updates on my ELGG (without miss my hack).

If you can use the function  "override_function" in your server it's all done, but i think this isn't the answer...

Do you know any way to do this?

Thanks!

I ended up overriding it with an override in the views menu described here:

http://openedweb.com/blog/2008/11/07/view-overrides-not-just-for-themes/

That worked for eliminating options, but I don't think it would work for adding functions as you are.

I believe one needs to provide the appropriate hook in the start.php, but what that was eluded me.

I remain interested in a solution. 

Steve

Im starting to think that is not going to be possible. We can only override views and actions but not other files in the core, at least as far as I know. Anyway, if I find something I will tell you.

Regards

I was wondering whether there's an update to this subject.

in my case, i am trying to override the following function within the file engine/lib/annotations.php:

function get_annotation($annotation_id) {...}

it's just 1 line, however, it gets easly forgotton for future upgrades..

Hi, Earthling,

I have never found a compelling case to override core lib files.  There is usually another way to do what you're trying to do, or else it's an enhancement/defect that should be fixed by Elgg itself.  What are you trying to accomplish?