I've read your awesome travel in T15659 but I've also read this inline comment:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jan 22 2024
It's nice and it works. So... thanks!
@aklapper @valerio.bozzolan I think the styles for remarkup should stay seperated. We shouldn't blur modular css definitions just to safe some lines or multiple declarations.
- Seperates styles
## Contents - is Phorge good for my Organization? - differences between Phorge and GitLab, GitHub, Launchpad, Mantis, ... - what's new in Phorge (that is not in Phabricator) - practical workflows and pitfalls - how to join the Phorge community - how to propose code patches
Jan 21 2024
Uh, right. So maybe we can:
Also remove unused $result array
I propose to remove that unused $result array. It's been unused before and looks we were not aware of any issues created by that fact.
Original change which triggered this: rP324470e39b0d4539a7487c2144157d686f5d0906
I cannot test it now, can you check who was setting that margin? Maybe we can try to avoid that !important
Jan 20 2024
I was able to trigger the "missing gd" warning (By uninstalling php*gd), so we're good there.
A bit puzzled about how you got the error if you already have it installed?
User content is also content, thus yes.
Jan 19 2024
Good question. Maybe also related to L2.
I'm still puzzled by the unused $result variable in line 46.
Is it assumed that using the site will automatically license the user’s content under these, or should there be a line for that?
In T15322#15031, @aklapper wrote:+1 on Content licensed under Creative Commons Attribution-ShareAlike 4.0 (CC-BY-SA) unless otherwise noted; code licensed under Apache 2.0 or other open source licenses.
Thanks!
In T15645#15201, @speck wrote:@bekay while in this area of code would you have any pointers on these other issues I’d like to fix at some point?
- File browse widget doesn’t work unless logged in, for publicly accessible repos
- The search results pop up width is often too narrow to show the full results path, and truncates the end of the path instead of beginning.
Values given in em units may produce unexpected results...
Adds return value to annotation and fixes wrong path when locating file from within a directory.
Tested locally and works in most cases, however would love to avoid creating broken (404) URIs due to T15579 before merging
Note that at least for Phame, http://phorge.localhost/J1 seems to always redirect to http://phorge.localhost/phame/post/view/1/blogpost/ instead of keeping the monogram in the URI.
So the baseURI is already wrong (not being http://phorge.localhost/ only) before concatenating the $ref (monogram and anchor).
As an ugly workardound, could probably make "Quote Comment" work by calling getObjectNamePrefix() in PhamePostRemarkupRule and LegalpadDocumentRemarkupRule and then use them in a preg_match to remove the monogram from the $ref but function is protected and... still ugly.
Jan 18 2024
@bekay while in this area of code would you have any pointers on these other issues I’d like to fix at some point?
- File browse widget doesn’t work unless logged in, for publicly accessible repos
- The search results pop up width is often too narrow to show the full results path, and truncates the end of the path instead of beginning.
Looks good! Thank you so much for this!
In D25505#14533, @avivey wrote:How about other functions that might require a logged-in user? "current Viewer's Projects" for example?
Yes. I think we should wait for a kind Administrator to implement the first one.
@speck @valerio.bozzolan My revision is ready to be tested 😄
- Adds map
In D25520#14909, @avivey wrote:Thanks
also - need to run bin/celerity map before landing?
Thanks
also - need to run bin/celerity map before landing?
please make the title more descriptive of the actual change (what it's doing) - "improve usability" is very vague.
maybe "don't hide title in search" or something like that.
Tested and I like it. Thanks :3
Uh thanks! You are now co-speaker
BTW I like the proposed screenshot. So I also agree to: feel free to share the solution 👍
My fix would work with this css class
I did not realize you had a fix. Please share it. :)
In T15715#15174, @aklapper wrote:I guess you could get the result that you're looking for by editing the file webroot/rsrc/css/aphront/typeahead.css and removing the line white-space: nowrap; from the definition of div.jx-typeahead-results a.jx-result. I just don't know which side effects this may have in other places...
Jan 17 2024
For parallel popcorn consumption, a slightly related (and slightly hung over) FOSDEM talk from 2015 with some shattered dreams included, from the perspective of an organization at that time: https://archive.fosdem.org/2015/schedule/event/wikimedia_adopts_phabricator/
I guess you could get the result that you're looking for by editing the file webroot/rsrc/css/aphront/typeahead.css and removing the line white-space: nowrap; from the definition of div.jx-typeahead-results a.jx-result. I just don't know which side effects this may have in other places...
If it's only for a small number of such words, they should probably just be added to the blacklist remarkup.ignored-object-names - in fact, we should probably add S3 at least as a default; And probably find a way to expose this config option. Maybe a button on the Remarkup box that will help adding things to the blacklist?
This patch is a cleaner approach to tackle T15676 than D25479 was.
In future steps,
- T15700: An "Integer" search field could be addressed (patch available for review),
- the type of the "Page Size" field in ManiphestTaskSearchEngine.php could be switched from PhabricatorSearchTextField to PhabricatorIntTextField - see T15723: Convert "Page Size" field in ManiphestTaskSearchEngine.php to PhabricatorSearchIntField,
- an AphrontFormIntControl class could be introduced to set type="number" for the control in the HTML,
- we could introduce an overwrite validateControlValue() function in PhabricatorSearchTextField.php as in theory, future code could accidentally pass invalid data types to setDefaultValue() - see T15714: Validate PhabricatorSearchTextField value
Jan 16 2024
Nah, I vaguely remember I accidentally set up something which didn't make sense and the followup PEBKAC moment when realizing but don't remember details now
In D25515#14842, @valerio.bozzolan wrote:I wonder if it then, upon deletion of the profile image, it attempts to delete the builtin image
In T15712#15124, @avivey wrote:Is the motivation only to allow not-magicking things like "S3" and "F1", or is there more?
Looks like the tickets end in a Wontfix in https://secure.phabricator.com/T5301; I didn't follow the whole thing, but often the reasoning in Remarkup boils down to performance.
mm, see this one: https://secure.phabricator.com/T5301#211340
Is the motivation only to allow not-magicking things like "S3" and "F1", or is there more?
Some help is needed there, testing on PHP 8.1+ and getting the right stack trace
I wonder if it then, upon deletion of the profile image, it attempts to delete the builtin image
Useful riepilogue for wild integers
Abandoning my patch becaue creating a child class for each and every single field does not scale.
Instead there should be a setDefaultValue() function on a PhabricatorSearchField level to be called by the SearchEngine.
Is that something we can improve in the settings page/docs - give better instructions on this setting?
Jan 15 2024
Indeed, this is invalid due to me not understanding the config settings at that time.