Development Discussion Board

Ok, I have now ready what would be an almost-complete solution for what I believe is doable without compromising performance, but maintaining the most possible availability and reliability.

I have not pushed it yet to github, as I would prefer to get your comments on the one that is published now ...

VSE wrote: Sun Jan 15, 2017 1:45 am

javiexin wrote: Sat Jan 14, 2017 10:21 pm forget about this completely

This will be a moot point once the Extension manager will be able to download extensions autmatically from our database.

And this is a moot point since that is probably at least one, more likely two years out.

-javiexin

Ok, second try pushed to GitHub. Still partial implementation, but also with some changes:

cache is now back in use, with a TTL set at 600 now (10 minutes) and we could make it whatever you think would be ok
the "configured" but not "available" extensions now show up in the ACP Extension List as ...

Ok, the issue now being performance, what alternatives do we have? We could set a TTL on the cache (currently, no TTL is set as far as I can tell), and only on cache expiration this will be checked. There would be certain exposition, but not much (a max of TTL, so depends on that), and the ...

But then, the migrations have run, and the database might be corrupt, and for sure not consistent.

I have now created the PR (WIP status): https://github.com/phpbb/phpbb/pull/4644

Current implementation is PARTIAL. Only eliminates the "not available" extension from the "configured" list.

In order for this to work as expected, the code from https://github.com/phpbb/phpbb/pull/4592 is required ...

I think that for the actual issue javiexin is talking about that the likely solution would have to be that is_enabled should return true only if is_available also returns true, which appears to be in the mentioned pull request. Not quite: the mentioned PR only makes is_available consistent with ...

Hi,

I am thinking about refactoring the template class, and I would be interested in your opinions.

The reasons for refactoring are basically of two kinds: redundant code (duplicated in several parts) and inconsistency in some aspects.

Also, I would like to take a look at usability of the ...

Hi,

I have found what I believe might be a bug in Extension Management, but it is not clear to me what is the best approach to solve it. I am all for implementing whatever suggestion comes out of here, just need guidance on what you believe is the best approach.

The situation: if an extension is ...

Well, I have another alternative: write a service replacement for fulltext_native.php...

Simplifying, what this would do would be: inherit from the current fulltext_native.php (in your own extension), then change whatever methods you need modified (not too easy, as I just glanced at the code, and ...