update celerity map

I thought we had "2 spaces" and the rest encoded as lints... I'll try to take a look.

hi I'm a space linter

Sorry, didn't see your earlier ping. Approved.

But reviewing this is the price @Matthew :D (you know ihih)

In D25362#10494, @valerio.bozzolan wrote:

Can I amend this change fixing spaces? I have some time to waste right now and I love this kind of "del del del" ihih

Can I amend this change fixing spaces? I have some time to waste right now and I love this kind of "del del del" ihih

Unfortunately, PHPStorm defaults to four spaces. I'm not really willing to spend a ton of time arguing with it (especially since my day job requires four spaces) ... though it would be helpful if we could come up with some clear code rules and them implement them in the repository using phpcs.

I'm not really opinionated in indentation but it seems the majority of the lines are indented with 4 spaces instead of two

So I'm following proposal n. 2 in D25363.

remove newline

Adjust spacing

Uh nice!

Fix lint errors

Here are some screenshots of this change in action:

I'm not able to reproduce anymore.

I think the problem here is that the command ./bin/cache purge --all does not reset the PhabricatorPeopleQuery cache.

Explicitly check for null instead of using phutil_nonempty_string()

I think you are misunderstanding the technical considerations.

I also like to discuss. Please read this:

If it is likely in principle that you would accept a patch, then it may be most sensible to leave the discussion open. Perhaps it would be found by someone wishing to contribute.

Again, you have not convinced me to work on that, for you, for free :)

Oh wow, that was quick, thanks @avivey . I will probably be able to apply the patch to our Phorge instance sometime next week, I'll let you know how it went!

I am not intent on maintaining my own fork for private use, but the processing pathways for the segmented versus consolidated cases are only minimally different, and may easily be switched dynamically, within some hypothetical future version of the application, depending on the deployment.

I understand your interest in this simplification. I think your opinion is helpful, useful, and I hope you will somehow solve your problem.

Your objection concerning the reference to Nextcloud is based on quote mining. It is neither germane nor accurate.

Note that Q67 tries to make similarities between LAMP apps like nextCloud and Phorge, but nextCloud has not 400+ database tables. This is just a minimal indication of the complexity, that may indicate that this design principle may be not totally suitable for this.

(comment migrated as answer)

In T15568#12244, @valerio.bozzolan wrote:

every extension should have its own

Ah, yeah, even better I think, if possible

You absolutely have the choice to decline requests, but I think it is not quite fair to consider the current one as though connected strongly to Softaculous.

every extension should have its own

I think we should avoid to extend PhutilURI for some interesting reasons:

In T15568#12239, @avivey wrote:

I was thinking of adding a script to ./bin to manage (mostly add/remove from load-libraries, maybe also clone) extensions.

Probably related, I think that any installed extension should not cause any touch to /src/__phutil_library_init__.php, as long as it's versioned in git in Phorge and so will cause of course merge conflicts after any update.

I was thinking of adding a script to ./bin to manage (mostly add/remove from load-libraries, maybe also clone) extensions.

@brainchild We receive feature requests here, and we have the choice to decline them here. The admin team has discussed it, we have decided that the current database setup works best for Phorge as is discussed in the documents avivey has linked. As such, changes will not be made to Phorge's database architecture at this time. If you are looking for something to provision with Softaculous, please consider a different solution.

I'd like to give this a shot, as part of streamlining extensions as discussed in T15568

I was thinking "out out", but only visible to admins - and then, only as a yellow notice at the top of the page:

I've explored a bit the codebase and this seems a desired non-feature.

This is a good plan. Would this be opt-in, e.g. this Phorge instance would be the main one with this on but other installs wouldn’t see this by default?

Where do you receive feature requests?

D25360 is probably the fix for the bug, but I'm not sure about how to test it yet. It's probably fine. No idea what would happen if you just re-encode a file and select an encoding...

Cool, I'll play with it and see what I can find.

Okay, I think I created a minimal example reproducing the problem. The repository is publicly available here: https://sourceforge.net/p/tinloaf-phorge-problem/code-hg/ci/default/tree/

This is also consistent with the installation notes where a toaster and other things are mentioned (since We live in interesting times).

For me, the larger observation is that because the general dependencies are aligned to the LAMP environment, an opportunity emerges for the project to be adapted as suitable for the shared hosting space. In principle, such adaptations are not dependent on removing features that support large-scale deployments on dedicated systems or more capable environments. Rather, such adaptations may simply support a greater variety of deployment cases.

Do you know off the top of your head whether the binary-detection in the commit view and the code browser view differ in some way?

To be clear - it's a single file in a single commit, in the equivalent of this page: https://we.phorge.it/rARCa604548101025875de20a9c263df3790fea425b3 - is that right?

Please understand that you are a stakeholder of interests that are just different from the current situation, and not necessarily because we don't know what we are doing :)