Recent content by NikitOS

Since the scripts in the public:color_picker_macros::color_picker_scripts macro are loaded in xf:head, they are not loaded in overlays, so the color picker can not be used here. Perhaps the contents of this macro should be taken out separately, so that it can be included on the page manually?

In 2.2, the event was called in the updateFromInput method. The current updateInputColor method does not do this.

Well, I meant ways that don't require such hacky solutions. I think there should be a normal solution out of the box, that's why I posted this suggestion.

Since 2.1.6, there is a postCompleteTransaction method in XF\Purchasable\AbstractPurchasable. However, there may be a need to watch all completed transactions for all Purchasables, for example for sending fiscal receipts to the tax service (not from a payment provider). Extending a class for...

@Memphis Foundry, the add-on should work. But I don't really understand how your users are stuck with the disabled style. Do you force it with my add-on?

In 2.2 the colors mixed correctly: But in 2.3, mixing these same colors gives this result: Yes, 2.3 uses HSL and the mixing algorithm is now different, but this algorithm mixes colors unnaturally.

To be clear, in XenForo out of the box there are no problems with this, since the only use case is grouping always visible buttons: But I needed to hide some buttons by default and display them via JS. And there is a problem: if the first or last button is hidden, the next or previous ones will...

New hardcoded string in 2.3.0 Beta 4: Passkey login in admin:login_form.

@Kirby, we are talking about duotone icons. Used icons can be styled as a whole, but duotone icons consist of two parts, and styles cannot be applied to them.

Progress bars in polls and attachments do not have a border. I don't think it should be here either. Also, the border-radius value should be replaced with @xf-borderRadiusMedium, as done in the polls: it looks much nicer. And in polls and attachments the progress_bar macro should be used.

Since specifying the image URL is optional, it makes sense to check if the URL is provided and not display the broken image:

Currently, EMBED_CONTAINER and OAUTH_CONTAINER call the public:helper_js_global::head macro. In addition, EMBED_CONTAINER also calls public:helper_js_global::body. The included JS is unnecessary and only causes errors. I think it’s better to move the inclusion of CSS out of the...

As said in the title. Template: <div class="block"> <div class="block-container"> <div class="block-body"> <xf:tokeninputrow label="Tags" placeholder="Enter something…" /> </div> </div> </div>

Demo:

The XF\Repository\EmbedResolver::addEmbedsToContent method should use array_merge_recursive instead of array_merge to collect all embeds in posts.