text:
Migrate the Undertemplate project to the toolbox

We maintain the Undertemplate project for our minor templating needs. It uses Lodash and makes the templating function CSP-compliant, removing the "eval"-code execution parts of the templating function.
We continue to have a need for Undertemplate, but it would be nice to drop the Lodash dependency and add TypeScript types. We could do so in the Undertemplate project itself, but now that we have the toolbox project that's installed in so many places, it's most convenient to maintain it here. Additionally, the Undertemplate implementation makes use of toolbox functions, so it's helpful to co-locate them.

Closed by https://github.com/silvermine/toolbox/pull/37

repo: silvermine/toolbox


text:
Verify ptau

https://github.com/silversixpence-crypto/zk-proof-of-assets/blob/257f872b07384f73e3581476613120f446196457/scripts/g16_setup.sh#L151-L152

Duplicate: https://github.com/silversixpence-crypto/zk-proof-of-assets/issues/42

source: gharchive/issue

license: MIT

license_type: permissive

license_source: github-api


text:
customize template in script-tab

Hi, thanks for this cool plugin, I've added 2 customization things:
1. custom index.html
After your first export, this patch will create the 'index.html'-template in the Script-workspace:

That way you can easily customize the exported index.html.
(Think adding analytics, JS, a-frame libraries e.g.).

NOTE: index.html is an internal text-file which gets saved into the .blend file. Awesome isn't it?

2. unknown AFRAME_* custom attributes will map to aframe attributes automatically
Let's say you're using an aframe plugin foo which is configurable using foo-attributes:

will then be generated as:
<a-entity .... foo-bar="{value)">

this is quite powerful, as it is impossible to just hardcode every possible future a-frame feature into this addon. Hope you like it.

Hi Leon!
Thanks for you pull: I like it very much!

source: gharchive/pull-request

authors: coderofsalvation silverslade


text:
Upon converting a page to a "Block Page" automatically create Content block with existing content

Often a CMS user may have a basic Page with some simple content in the Content area.
At some point, they may then wish to convert this Page to a Blocks Page in order to add extra elements.
However, when they do this, all existing content is removed without warning. Not a great user experience. Many users won't know that reverting the page to a Page will bring back the content.
Perhaps, upon the change of type to a Block Page, it could automatically create a Content block containing all the initial content fro the original page's Content field. Then the CMS user is free to add more blocks, and edit or remove the original content as they wish.

We already have a task that does this:
https://github.com/dnadesign/silverstripe-elemental/blob/4/src/Tasks/MigrateContentToElement.php
Perhaps we can move the relevant logic to a standalone service and then use it both in the task and some hook on conversion to a block page?
I'd be happy to review a PR if you feel up to it?

Can be achieved with a simple addition to onAfterWrite() on your "BlocksPage" (which isn't included in the Elemental module, so I won't worry about a PR):
<?php

namespace PurpleSpider\MySite;

use Page;
use DNADesign\Elemental\Models\ElementContent;
use DNADesign\Elemental\Extensions\ElementalPageExtension;

class BlocksPage extends Page {

    private static $table_name = 'BlocksPage';
    private static $description = 'A modular page composed of content blocks';
    private static $icon_class = 'font-icon-p-alt-2';

    private static $extensions = [
        ElementalPageExtension::class,
    ];

    public function onAfterWrite()
    {
        // If just converted: copy any Content to a new Content block
        if($this->Content) {
            if($area = $this->ElementalArea()) {
                if(!$area->Elements()->exists()) {
                    $element = ElementContent::create();
                    $element->ParentID = $area->ID;
                    $element->Title = "Content";
                    $element->HTML = $this->Content;
                    $element->write();
                }
            }
        }

        parent::onBeforeWrite();
    }

}

authors: ScopeyNZ purplespider

repo: silverstripe/silverstripe-elemental


text:
[Bug] TinyMCEConfig breaks when using option extended_valid_elements on a custom Config.

Module version(s) affected
4.13.30-4.13.42
Description
Upon upgrading a site from 4.13.29 to 4.13.41 a bug was introduced in our TinyMCE editor. Nearly all formatting is being stripped on save. It appears as though only html elements listed in extended_valid_elements are being allowed, as if the list is being used to replace the list of valid elements rather than amend it.
How to reproduce
Define an extended valid elements value for a custom TinyMCE config in _config.php.
TinyMCEConfig::get('CustomConfig')
    ->setOptions(['extended_valid_elements' => 'small']);

Add a custom field using this config in Page.php
        private static $db = [
            'RichTextField' => 'HTMLText'
        ];

        public function getCMSFields()
        {
            $fields = parent::getCMSFields();
            $fields->addFieldToTab('Root.Main', HTMLEditorField::create('RichTextField', 'RichTextField', $this->RichTextField, 'CustomConfig'));
            return $fields;
        }

Open a TinyMCE editor in the CMS and enter paragraph breaks, links or any other formatting. On save, all such formatting is stripped.
If the extended_valid_elements option is removed, or set to an empty string, the issue does not occur.
If you set the value to 'h3', you will be able to save h3 elements, but nothing else.
Possible Solution
This bug does not appear in 4.13.29, but it appears in all versions after 4.13.30
The change in 4.13.30 appears to cause custom configs to be built from an empty config, instead of bootstrapping the defaults as it did previously.
https://github.com/silverstripe/silverstripe-framework/commit/e5eb98cc3491785cbae17bb53be0be05fd5a6f42#diff-816b9855682fea334353bdfeb9b733211672205ec14351283df7dc1289f89037L148
Reverting this change would fix my issue, but I'm not clear what problem it was trying to solve. In any case this was a breaking change in config behaviour.
Additional Context
No response
Validations

[X] Check that there isn't already an issue that reports the same bug
[X] Double check that your reproduction steps work in a fresh installation of silverstripe/installer (with any code examples you've provided)

PRs

https://github.com/silverstripe/silverstripe-framework/pull/11142

Would appreciate any insight from maintainers here on what the intended behaviour is here. Have I been exploiting a bug that I took for a feature and which 4.13.30 fixed, or did 4.13.30 introduce a bug?

If anyone else is seeing this bug, we were able to fix the particular issue with extended_valid_elements by doing this:
$valid_elements = TinyMCEConfig::get('cms')->getOption('valid_elements');
$valid_elements .= ',small';

TinyMCEConfig::get('CustomConfig')
    ->setOptions(['extended_valid_elements' => $valid_elements]);

The above fix however assumes that only the valid element list is being wiped out. If we assume that any number of config options could be being affected, we need to programatically clone and pass along all of them. See below.
$default_options = json_decode(TinyMCEConfig::get('cms')->getAttributes()['data-config'], true);

$createConfig = function ($name) use ($default_options) {
    $config =  TinyMCEConfig::get($name);
    foreach ($default_options as $key => $value) {
        if ($key === 'external_plugins') {
            $config->enablePlugins($value);
            continue;
        }
        if ($key === 'toolbar') {
            foreach ($value as $line => $buttons) {
                $config->setButtonsForLine($line + 1, $buttons);
            }
            continue;
        }
        $config->setOption($key, $value);
    }
    return $config;
};

$createConfig('CustomConfig')
    ->setOptions(['extended_valid_elements' => 'small']);

Expected behaviour is that the configuration set for a given HTMLEditorConfig instance is used for validation.
If extended_valid_elements and valid_elements are set for a given config instance, then that is what should be used to validate the HTML.
To check:

In 4.13.29 was the set of valid elements being validated against actually set on the given HTMLEditorConfig instance?

Check by calling getOption('extended_valid_elements') and getOption('valid_elements')

After 4.13.30 is the set of valid elements being validated against set on the HTMLEditorConfig instance (i.e. did the change in 4.13.30 actually change the config itself?

Looks like this is acting as expected.
use SilverStripe\Forms\HTMLEditor\TinyMCEConfig;
$config = TinyMCEConfig::get('CustomConfig');
$config->setOptions(['extended_valid_elements' => 'small']);
var_dump([
    'valid_elements' => $config->getOption('valid_elements'),
    'extended_valid_elements' => $config->getOption('extended_valid_elements'),
]);

This outputs
array(2) {
  ["valid_elements"]=>
  NULL
  ["extended_valid_elements"]=>
  string(5) "small"
}

In otherwords, previously your config wasn't being validated correctly - but now it is.
In hindsight if we'd known this would be a problem we would have held off releasing this change until a minor release in CMS 5, but now that it's out there reverting it would just cause problems for people who have already updated and are relying on the now-correct behaviour.

@GuySartorelli this output does not explain the TinyMCE behaviour.
Stripping of tags only occurs when extended_valid_elements is set. If you do the following:
use SilverStripe\Forms\HTMLEditor\TinyMCEConfig;
$config = TinyMCEConfig::get('CustomConfig');
var_dump([
    'valid_elements' => $config->getOption('valid_elements'),
    'extended_valid_elements' => $config->getOption('extended_valid_elements'),
]);

This outputs
array(2) {
  ["valid_elements"]=>
  NULL
  ["extended_valid_elements"]=>
  NULL
}

The above is true in both 4.13.29 and 4.13.30-42. And in all versions you are able to save  tags,  tags etc.
If the validator is intended to remove any elements not in the list then it should not be possible to save any such markup after 4.13.30. The issue here is that setting extended_valid_elements seems to actually decrease the number of valid elements the editor will accept after 4.13.30.
It would seem very odd to me if this was the intended behaviour.

Stripping of tags only occurs when extended_valid_elements is set

Ahh okay thank you, I must have skipped over that part of the original description, that's good context to have. I'll take a look at that side of it.

Probably also worth noting that a new TinyMCEConfig, w/ no modifications applied will load on the frontend w/ a number of buttons in the toolbar to generate various HTML tags. Headings, lists, tables, etc. If the idea is to wipe the valid_elements list clean unless specified, I would also thing the button rows should be wiped clean so we don't have the interface to add elements that will not be allowed.

My current approach (and I passed this by @blueo who implemented the fix you linked to in the original issue description) is to explicitly set some default valid_elements for all new config (which gets overridden of course if you explicitly set valid_elements yourself).
This retains the current behaviour for new configs that don't have any explicit valid_elements or extended_valid_elements config defined for it, but it doesn't cause unexpected behaviour when all you set is extended_valid_elements, because the valid_elements is still set to a sane default.
So it keeps the good part of the current behaviour, and removes the unexpected element. Hopefully.
Does that sound about right to you?

Or if you'd like to amend yours to be along those lines, that works too 🥳

Yes, I think there should be a default set of valid_elements, presumably set in TinyMCEConfig::$settings?
I guess my question would then be what are the default valid elements? Willing to work on a PR but I'm not sure how such defaults have been, or should be arrived at.
There is a list defined in silverstripe/admin/_config.php for the 'cms' config. Should that be the default? If so presumably we want a single source of truth rather than copy pasting? Why does the 'cms' config include both valid_elements and extended_valid_elements? I would have assumed it would all be in valid_elements and extended_valid_elements would be left blank for developers to be able to extend the list without overriding items from the existing list. Perhaps the docs could/should make it clear the best way to modify this part of the config?
The 'cms' config defines quite a few allowed attributes, not just the element type. How was this list arrived at?
Presumably we want to align the default valid elements list with the default set of buttons and plugins? Is there any way we can derive the default elements from these other options or otherwise ensure that a change in one is reflected by a change in the other?
$config = TinyMCEConfig::get('Custom');
print_r([
    'buttons' => $config->getButtons(),
    'plugins' => $config->getPlugins()
]);

Output
Array
(
    [buttons] => Array
        (
            [1] => Array
                (
                    [0] => bold
                    [1] => italic
                    [2] => underline
                    [3] => removeformat
                    [4] => |
                    [5] => alignleft
                    [6] => aligncenter
                    [7] => alignright
                    [8] => alignjustify
                    [9] => |
                    [10] => bullist
                    [11] => numlist
                    [12] => outdent
                    [13] => indent
                )

            [2] => Array
                (
                    [0] => formatselect
                    [1] => |
                    [2] => paste
                    [3] => pastetext
                    [4] => |
                    [5] => table
                    [6] => sslink
                    [7] => unlink
                    [8] => |
                    [9] => code
                )

        )

    [plugins] => Array
        (
            [table] =>
            [emoticons] =>
            [paste] =>
            [code] =>
            [importcss] =>
            [lists] =>
        )

Front-end

Most of those questions are about past decisions, so I can't answer any of those.
The one I can answer (sort of) is what the default valid elements should be. And that's simply "whatever is currently allowed when you try to sanitise a new config which hasn't had its valid elements defined"

Looks like the set of valid elements that TinyMCE uses by default (which is what's applied in that scenario since the PHP sanitiser is effectively skipped) was nice and clearly defined in TinyMCE 3, but in 4 they don't hard code it.
That said, it can be derived from tinymce.get()[0].parser.schema.elements - so I'm gonna explore that avenue tomorrow.

Attempting to generate the string we need then.
Object.keys(tinymce.get()[0].parser.schema.elements).reduce(function (previous, key) { return (previous ? previous + "," : '') + key + '[' + Object.keys(tinymce.get()[0].parser.schema.elements[key].attributes).join('|') + ']'; }, "");

Output
acronym[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],applet[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|codebase|archive|code|object|alt|name|width|height|align|hspace|vspace],basefont[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|size|color|face],big[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],font[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|size|color|face],strike[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],tt[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],center[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],dir[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|compact],isindex[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|prompt],noframes[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],html[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|manifest],head[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],br[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|clear],noscript[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],hr[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|align|noshade|size|width],title[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],base[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|href|target],link[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|href|rel|media|hreflang|type|sizes|crossorigin],meta[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|name|http-equiv|content|charset],style[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|media|type|scoped|xml:space],body[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|onafterprint|onbeforeprint|onbeforeunload|onblur|onerror|onfocus|onhashchange|onload|onmessage|onoffline|ononline|onpagehide|onpageshow|onpopstate|onresize|onscroll|onstorage|onunload|background|bgcolor|text|link|vlink|alink],caption[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|align],div[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|align],dd[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],dt[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],address[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],dfn[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],cite[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],s[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],small[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],strong[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],em[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],legend[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|align],span[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],bdo[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],u[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],b[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],i[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],sup[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],sub[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],kbd[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],samp[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],var[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],code[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],abbr[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],p[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|align],pre[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|width|xml:space],h6[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|align],h5[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|align],h4[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|align],h3[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|align],h2[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|align],h1[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|align],blockquote[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|cite],ol[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|reversed|start|type|compact],ul[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|type|compact],li[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|value|type],dl[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|compact],a[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|href|target|rel|media|hreflang|type|charset|name|rev|shape|coords|download],q[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|cite],del[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|cite|datetime],ins[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|cite|datetime],img[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|src|sizes|srcset|alt|usemap|ismap|width|height|name|longdesc|align|border|hspace|vspace|crossorigin],iframe[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|src|name|width|height|longdesc|frameborder|marginwidth|marginheight|scrolling|align|sandbox|seamless|allowfullscreen],embed[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|src|type|width|height|align|name|hspace|vspace],object[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|data|type|typemustmatch|name|usemap|form|width|height|declare|classid|code|codebase|codetype|archive|standby|align|border|hspace|vspace],param[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|name|value|valuetype|type],map[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|name],area[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|alt|coords|shape|href|target|rel|media|hreflang|type|nohref],table[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|border|summary|width|frame|rules|cellspacing|cellpadding|align|bgcolor],colgroup[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|span|width|align|char|charoff|valign],col[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|span|width|align|char|charoff|valign],tfoot[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|align|char|charoff|valign],thead[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|align|char|charoff|valign],tbody[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|align|char|charoff|valign],tr[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|align|char|charoff|valign|bgcolor],td[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|colspan|rowspan|headers|abbr|axis|scope|align|char|charoff|valign|nowrap|bgcolor|width|height],th[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|colspan|rowspan|headers|scope|abbr|axis|align|char|charoff|valign|nowrap|bgcolor|width|height],form[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|accept-charset|action|autocomplete|enctype|method|name|novalidate|target|accept],fieldset[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|disabled|form|name],label[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|form|for],input[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|accept|alt|autocomplete|checked|dirname|disabled|form|formaction|formenctype|formmethod|formnovalidate|formtarget|height|list|max|maxlength|min|multiple|name|pattern|readonly|required|size|src|step|type|value|width|usemap|align|autofocus|placeholder],button[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|disabled|form|formaction|formenctype|formmethod|formnovalidate|formtarget|name|type|value|autofocus],select[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|disabled|form|multiple|name|required|size|onchange|autofocus],optgroup[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|disabled|label],option[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|disabled|label|selected|value],textarea[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|cols|dirname|disabled|form|maxlength|name|readonly|required|rows|wrap|autofocus|placeholder],menu[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|type|label|compact],wbr[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],ruby[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],figcaption[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],bdi[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],summary[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],rp[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],rt[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],mark[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],canvas[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|width|height],video[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|src|crossorigin|poster|preload|autoplay|mediagroup|loop|muted|controls|width|height|buffered],audio[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|src|crossorigin|preload|autoplay|mediagroup|loop|muted|controls|buffered|volume],picture[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],source[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|src|srcset|type|media|sizes],track[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|kind|src|srclang|label|default],datalist[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],footer[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],header[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],main[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],aside[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],nav[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],section[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],article[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],hgroup[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],figure[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang],time[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|datetime],dialog[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|open],command[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|type|label|icon|disabled|checked|radiogroup|command],output[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|for|form|name],progress[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|value|max],meter[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|value|min|max|low|high|optimum],details[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|open],keygen[id|accesskey|class|dir|lang|style|tabindex|title|role|contenteditable|contextmenu|draggable|dropzone|hidden|spellcheck|translate|xml:lang|autofocus|challenge|disabled|form|keytype|name]

Applying the above string w/ $config->setOption('valid_elements, $string) and then checking tinymce.get()[0].parser.schema.elements in the browser results in similar, but not identical results to just running tinymce.get()[0].parser.schema.elements for an unmodified config.
Unmodified version includes this for a.attributes.xml
        "xml": {
            "forcedValue": "lang"
        }

But in the one where we've passed in the string via PHP we get
        "xml:lang": {},

Unmodified has an attributesForced value w/ elements.a
    "attributesForced": [
        {
            "name": "xml",
            "value": "lang"
        }
    ]

Configured w/ php there's no attributes forced but there is
        "removeEmpty": true

Not sure if these make a big enough difference to be concerned about, nor do I know how to pass in a string that would make the results identical.

That's the direction I was going with some of my questions but if the goal here is to restore the functionality that broke in v4.13.30 and not disrupt anyone else's configuration which may for some reason depend on the permissive settings the TinyMCE defaults make sense. Restoring what broke is a different task than revisiting the expectations, I suppose.

The generated default above appears very permissive and maybe we should err on the side of 'sensible defaults' for a CMS product?

How do you decide which defaults are "sensible"? What do we do when we change to a less permissive default set and it breaks someone's site because they're relying on the permissive set that we currently use?
That's definitely something we can look at doing in a major release where our opinion of what is sensible is allowed to be a breaking change, but for now we just want to not break things when extended_valid_elements is defined. It's a very narrow scope bug fix.

Although... actually. Now I'm thinking (which is always dangerous)... in 4.13.29 it wouldn't have been the full TinyMCE set would it? It would have been the "current config" set I think. So maybe we can just take the set that'd defined on cms and call it a default?
Thoughts on that?

Hmm yeah I think it was essentially defaulting to the cms config for all sanitisation as it would get set here: https://github.com/silverstripe/silverstripe-admin/blob/2/code/LeftAndMain.php#L688
Well that assumes that the user would generally have CMS as their config

Well that assumes that the user would generally have CMS as their config

That's a good point.

All this discussion makes it pretty clear this issue needs a bit more thought put into how we choose to solve it - I've put it into our internal refinement column so we can discuss the options internally

There's an underlying issue here of why setting extended_valid_elements changes the behaviour of valid_elements. Is that a TinyMCE issue or something to do with Silverstripe's particular use of it? Kind of seems like we're working out how to patch around this quirk without identifying why this quirk happens.

So we definitely need to rip that condition out to get the valid elements respected properly. But we also have to add some default valid elements so we're not just stripping everyone's HTML out of their not-quite-configured-enough WYSIWYGs

FYI we have discussed this internally and added some acceptance criteria to the card.
@davejtoews if you're keen to try update your PR to meet these criteria please feel free - if not, one of the CMS Squad will tackle this in the near future.
The decision was ultimately:

Revert the bugfix that caused this bug in patch releases. That's less likely to cause disruption than trying to fix this bug in a patch release.
In a future minor release (it'll be in 5.3 unfortunately, we missed the window for 5.2), use the current "cms" set of elements as a default set of valid_elements since it is the behaviour most people will have been seeing prior to that original bugfix (assuming most people didn't alter the "cms" config)

Linked PRs have been merged and will be released as part of the Silverstripe 5.3 release

authors: GuySartorelli blueo davejtoews emteknetnz

repo: silverstripe/silverstripe-framework


text:
BUG: last column in grid field not showing label

I have set up a simple dataobject and added it as a gridfield to a page:
The model definition is as follows:

    private static $db = array(
        "Email" => "Varchar",
        "Code" => "Varchar",
        "Used" => "Boolean",
        "DownloadTimes" => "Int"
    );

    private static $casting = array(
        "UsedNice" => "Varchar"
    );

    private static $summary_fields = array(
        "Created" => "Sent",
        "Email" => "Email",
        "UsedNice" => "Has Been Used",
        "DownloadTimes" => "Times Downloaded"
    );

    private static $searchable_fields = array(
        "Email",
        "Used"
    );

Looks great - now lets sort the fields (clicking on one of the sort buttons) ...
As you can see, the last column header seems to disappear after you click on sort ...

And also seen:

This could be improved I reckon.
Another few issued I noticed:

it might be better if the gridfield used the searchable_fields values rather than just any field in terms of deciding what columns are searchable
you have to sort first before realising you can search.
when you do a search, but you click on the "cancel" cross, the view shifts to the top of the page while it should just stay where you are.

BEFORE:

AFTER:

The clear button for the field is dropped too low:

The alignment for the search fields seems to be out (last one is dropped):

Hey I know this ticket has been around a while, @sunnysideup — do you know if these issues are also present in SS4? It would be great if you could test.

I think the issue is that gridfield only works properly if the last column is the actions column. It's probably still an issue in ss4.

Related https://github.com/silverstripe/silverstripe-framework/issues/1835

Sorry, I do not have time to look at this right now.  As soon as I have time, I will..

authors: sminnee sunnysideup tractorcow


text:
Remove Link and File Tracking until they make sense to user.

Affected Version
Latest stable version of SS
Description
When I install the latest version of SS I now get some weird stuff about Link and File Tracking. I am sure this is really important but it is completely meaningless to the Content Editor. I have created one site where I have simply hidden the two tabs on the 10 Models or so.
I would recommend we remove their visibility from the CMS until someone has looked at this from a user's perspective. What do they do, what are they for, why do I need them, etc... etc...

There's been a lot of work in this area over the last few months. I think it's been disabled for models like members etc, can you please pull in the latest 4.2.x-dev branch and see if that is any better?

Thanks @ScopeyNZ. Closing as a duplicate of those

Thank you for your quick reply. Great to see that it has been fixed. Weird how something as major as that gets released. I mean, so much of the SS work is completely brilliant and all that, but it seems we sometimes forget the end goal: the user experience.

Thanks @sunnysideup. There's always a lot going on in the core development, and sometimes things slip through unnoticed for some time.

Totally, I understand that better than anyone else.  I guess what I am advocating is that perhaps more emphasis be placed on the user experience. I, for one, would be super happy to test a new release before it goes live. I am sure others would too.  The cost of such a test would be minimal in comparison to the costs of dealing with it after it has been released (i.e. AFAIK these Tracking Tabs are now on every CWP install).

authors: robbieaverill sunnysideup


text:
MINOR: make debug query easy-ish to parse

When you get 100s / 1000s of queries from ?&showqueries=backtrace and the like, it is great to have a way to, for example, find the slowest queries.  Having some characters to split the text into columns, etc... is useful here.

Would adding labels be a better way than just ###?
Something like:
\n Query ($queryCount): $query
\n Time (s): $endtime

Closing for now - I agree that # isn't ideal. If you want to proceed with this, feel free to reopen and change to something sane that clearly labels each item.

authors: GuySartorelli michalkleiner sunnysideup


text:
Various deprecations and a few features

The commits in this PR are intentionally separated, do not squash.

Deprecate DatabaselessKernel and merge that functionality into CoreKernel instead - and add BaseKernel::getBooted() (see src/Cli/Sake.php)
Implement two new methods for ArrayLib (see src/Cli/LegacyParamArgvInput.php)
Implement a new method for DBDateTime (see src/Dev/BuildTask.php)
Various deprecations for stuff that's getting deleted in https://github.com/silverstripe/silverstripe-framework/pull/11353

Makes sense to add the non-API-breaking new features into this minor instead of having it in the 6 PR.
Issues

https://github.com/silverstripe/silverstripe-framework/issues/11341

Rebased to resolve conflict


text:
allow themed renderWith even if theme is disabled

$this->renderWith(foo)

called while the user is editing the CMS (e.g. when creating a newsletter) often leads to unexpected results: the theme of the site is not being used and therefore no themed templates can be found because the CMS turns of the site's theme (for good reasons).
This proposed addition to the renderwith method allows devs to render in theme style even if called from within the CMS (of other situations where the theme is disabled).
Maybe it will be better to allow it to work both ways - so that you can choose with or without theme. I am happy to resubmit of course.
Nicolaas

@tractorcow @sunnysideup did we want to progress this one or close it off? Note that it would have to be rebased to the 3 branch.

I am keen, but offer nothing because I am short of time. Sorry.

If we’re adding this to 3, here’s an alternative suggestion that saves a few lines of code:
Config::nest();
if ($forceTheme) {
    Config::inst()->update('SSViewer', 'theme_enabled', true);
}

// ... render stuff

Config::unnest();

As I type this I have a concern entering my mind, though: what’s the additional memory footprint of nesting config?

Anyone who is keen to work on this feel free to re-open with an update.

authors: kinglozzer sminnee sunnysideup


text:
Problem with GUI test on appveyor and travis

I guess system pops can explain things...

Well, it looks to be not the case on appveyor:

Did you tried the registry patch proposed in: https://github.com/appveyor/ci/issues/1715?

Yes, but it have to be applied before our scripts have hands on it, else it have no effects.

I create a branch to play around that https://github.com/silx-kit/silx/pull/1024 (it should fix problems a have with the mouse, but not this one, it also introduce few other things we can cherry pick one of this days)
And GUI tests was disabled by https://github.com/silx-kit/silx/pull/1050 while it is not fixed

And i have no feed back from Travis

Travis answer that they will check it is possible to disable the popup. But ask us if we can close it by our-self. I think it is not so easy while we never know when and when the dialog pop.

repo: silx-kit/silx


text:
Lot of bugs

Hi there
After installing the scripts, I had no accesss to screeen and sleep ( I want to remove group policy, how to do that ?)
the snipping tool also was not saved in screenshot folder ? why ?
Can you help me out to fix those bugs ?

Hi there
After installing the scripts, I had no accesss to screeen and sleep ( I want to remove group policy, how to do that ?)

Please review the documentation to adjust those settings

https://github.com/simeononsecurity/Windows-Optimize-Debloat/blob/main/README.md#editing-policies-in-local-group-policy-after-the-fact
https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/managing-power-with-group-policy-part-1-of-3/ba-p/395121

the snipping tool also was not saved in screenshot folder ? why ?

We're not sure what you mean here, can you elaborate?. Try using the Win + Shift + S shortcut to the screenshot tool instead.

Hi
I want to remove those in firefox, chrome, internet explorer

It's so annoying

Hi I want to remove those in firefox, chrome, internet explorer

It's so annoying

Please review the readme
The instructions to modify those options is in
https://github.com/simeononsecurity/Windows-Optimize-Debloat#additions-notable-changes-and-bugfixes
Additionally, this topic is closed. Please open a new issue if you're having new issues. Otherwise, please open a discussion if you have questions.

authors: mrbateuk simeononsecurity


text:
Start a select with the Dart API without specifiying a table

Would it be possible to do something like selectExpressions([expr1, expr2]) with the Dart API?
The use case would be creating the query SELECT EXISTS (SELECT * FROM t1) AS is_empty with the Dart API

Just to make sure I'm not missing anything obvious, you'll never need limit/where/order/joins here right? So the API would essentially be Selectable<TypedResult> selectExpressions(Iterable<Expression> expressions) without a possibility of modifying the statement afterwards.

@simolus3 I can't currently see any usage for joins, but maybe WHERE could end up being useful.
Although selecting an expression + a where is technically creating a subquery with the WHERE right? So unless it's trivial to add it might not be worth it

Although selecting an expression + a where is technically creating a subquery with the WHERE right?

I don't think so, because columns from t1 are not in scope on the outer select without a FROM clause. So the WHERE couldn't really refer to anything either way. It would mean that the select returns either zero or one rows, but I can't come up with a scenario where that is useful.

Thanks Simon!

license: mit

license_source: bigquery


text:
issue when generating Create Table

Hello,
I am creating a class table which has 2 fields that has default value, here the code
class SocialItems extends Table {
  IntColumn get id => integer().nullable()();

  TextColumn get type => text()();

  TextColumn get data => text()();

  TextColumn get name => text().withDefault(const Constant(""))();

  TextColumn get asset => text().withDefault(const Constant(""))();

  @override
  Set<Column> get primaryKey => {id};
}

when database is creating, It generate a wrong SQL like that
CREATE TABLE IF NOT EXISTS social_items (id INTEGER NULL, type VARCHAR NOT NULL, data VARCHAR NOT NULL, name VARCHAR NOT NULL DEFAULT ?, asset VARCHAR NOT NULL DEFAULT ?, PRIMARY KEY (id));)

but it must generate like this
CREATE TABLE IF NOT EXISTS social_items (id INTEGER NULL, type VARCHAR NOT NULL, data VARCHAR NOT NULL, name VARCHAR NOT NULL DEFAULT '', asset VARCHAR NOT NULL DEFAULT '', PRIMARY KEY (id));

My question is my table definition is wrong or there is an issue the library ? and how to solve this ?
Thanks

The main reason we don't generate string literals for Constant<String> expressions is that I didn't want to deal with sql injection vulnerabilities. I guess they shouldn't be that hard to handle though, we only need to escape two chars.
That said, does the create statement not work? Moor should bind the variable ? to the appropriate value. If sqlite rejects variables as defaults we should definitely look into generating literals instead.

Yes. The create statement not working and table not created. in the debug shows ? for default value.

We now support writing string literals (which are used to represent Constant<String> expressions in sql) on the develop branch, so this will be in the next version of moor.
If you really need it urgently, a current workaround would be to create the table in sql instead.

Thanks so much for your quick responses.


text:
Long FPS drop when opening all packages list

FPS drop takes ~20s on my end to open while stopping me from doing anything.

Two options:

Remove the feature
Add a dialog

There's absolutely nothing I can do about it sadly, it has to read the bundle files for sizes, would be probably better to just remove the sizes honestly.

authors: Luffyyy RexTheWho


text:
🛑 Hailer Training is down

In 4b0e667, Hailer Training (https://$HT_SITE1/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Hailer Training is back up in 9ad51cd after 4 minutes.


text:
io.netty.handler.codec.EncoderException: String too big

Click [+]
Click Permissions
Click Users
Click my UUID
[15:09:43] [Server thread/INFO] [nucleus]: Breantique ran the command: /chatui newtab
[15:09:45] [Server thread/INFO] [nucleus]: Breantique ran the command: /sponge:callback e3acfb25-0358-46bd-90d5-dc32cfac6547
[15:09:47] [Server thread/INFO] [nucleus]: Breantique ran the command: /sponge:callback 3bb6e497-2856-4c3e-9854-d3d3d7428824
[15:09:54] [Server thread/INFO] [nucleus]: Breantique ran the command: /sponge:callback 37959b97-19b9-4de3-b2a4-6a4357701073
[15:09:54] [Netty Epoll Server IO #0/ERROR]: io.netty.handler.codec.EncoderException: String too big (was 60247 bytes encoded, max 32767)
[15:09:54] [Server thread/INFO]: Breantique lost connection: Internal Exception: java.io.IOException: Error while read(...): Connection reset by peer
It does the same with group
Forge 2297
Sponge 5.2.0-2328
ChatUI 1.0.0
LuckPerms 3.1.51
Edit:
I am also wondering where it gets the UUIDs for the permissions>users list.
I am the only one that has ever joined the current world on the server, and the only place the other players are listed is on the old PEX database.  I don't see any database connection options, so I doubt that's the case

More than three days and no one has any suggestions on how to fix this?

Sorry, I don't have much free time to work on Chat UI right now.
The problem is due to a hard limit on the size of the serialised JSON string sent in a single packet. There must be a lot of formatted text in the chat (colors, click/hover actions etc). I didn't encounter this when testing myself but it's totally possible. The fix would be to make ChatUI split large JSON into smaller packets (e.g. sending 1 packet per line instead of 1 for the whole text area).
If the permissions tab is the only thing that breaks then I suggest don't use it for now.

I understand.  Work or school and all that.  I didn't mean to sound impatient.
I have taken chatui out for now.  It was a luxury not a requirement.  I plan on finishing up my setup and revisiting chatui in maybe the next release


text:
Support npm ci with a package-lock.json

We don't currently npm install prior to deployment so there is no package-lock.json generated in the dist folder.
It's not ideal to run npm install prior to every build/deploy, but the package-lock.json would be useful for the following reason (comment from another repo)

From my understanding, when deploying to Cloud Functions, Cloud Build installs your dependencies with npm ci, but your apps/api directory doesn't have a package-lock.json file, so your dependencies are installed in a non-deterministic way, which isn't desirable. If any dependency (e.g. firebase-functions) were introduced a bug in a minor release, this bug would suddenly appear on production.

Possibly  npm install --package-lock-only might do it...

I've successfully deployed using plugin v0.3.4 against a 13.10.6 Nx workspace, with node version 14, and 16, firebase-tools 10.8.0 with no issues.
Closing this.

repo: simondotm/nx-firebase


text:
"llama_cpp not installed" even after I install it

Maybe llm and pip are not installing stuff in the same environment? 🤔
$ llm --version
llama_cpp not installed, install with: pip install llama-cpp-python
llm, version 0.12

~/git/zeke/dotfiles main*
$ pip install llama-cpp-python

Requirement already satisfied: llama-cpp-python in /Users/z/.pyenv/versions/3.10.4/envs/python-3.10.4/lib/python3.10/site-packages (0.2.20)
Requirement already satisfied: typing-extensions>=4.5.0 in /Users/z/.pyenv/versions/3.10.4/envs/python-3.10.4/lib/python3.10/site-packages (from llama-cpp-python) (4.8.0)
Requirement already satisfied: numpy>=1.20.0 in /Users/z/.pyenv/versions/3.10.4/envs/python-3.10.4/lib/python3.10/site-packages (from llama-cpp-python) (1.26.1)
Requirement already satisfied: diskcache>=5.6.1 in /Users/z/.pyenv/versions/3.10.4/envs/python-3.10.4/lib/python3.10/site-packages (from llama-cpp-python) (5.6.3)

~/git/zeke/dotfiles main*
$ llm --version
llama_cpp not installed, install with: pip install llama-cpp-python
llm, version 0.12

cc @simonw

Just tried again but still seeing this error.
$ brew upgrade llm
Warning: llm 0.12 already installed

$ llm --version
llama_cpp not installed, install with: pip install llama-cpp-python
llm, version 0.12

$ which llm
/opt/homebrew/bin/llm

$ pip install llama-cpp-python
Requirement already satisfied: llama-cpp-python in /Users/z/.pyenv/versions/3.10.4/envs/python-3.10.4/lib/python3.10/site-packages (0.2.20)
Requirement already satisfied: typing-extensions>=4.5.0 in /Users/z/.pyenv/versions/3.10.4/envs/python-3.10.4/lib/python3.10/site-packages (from llama-cpp-python) (4.8.0)
Requirement already satisfied: numpy>=1.20.0 in /Users/z/.pyenv/versions/3.10.4/envs/python-3.10.4/lib/python3.10/site-packages (from llama-cpp-python) (1.26.1)
Requirement already satisfied: diskcache>=5.6.1 in /Users/z/.pyenv/versions/3.10.4/envs/python-3.10.4/lib/python3.10/site-packages (from llama-cpp-python) (5.6.3)

This is working for me now.
$ llm --version
llm, version 0.13.1

repo: simonw/llm-replicate


text:
Allow asserting against the root element (e.g. without target).

The following should be possible:
test('element has class', function(assert) {
  assert.dom().hasClass('data-foo');
});

However, the following error is thrown:
TypeError: Unexpected Parameter: undefined

The current work around (in Ember's moduleForComponent parlance) is:
test('element has class', function(assert) {
  this.render(hbs`{{some-thing}}`);

  assert.dom(this._element).hasClass('foo');
});

I am a little worried about this out of several reasons:

it looks like glimmer just moved away from this.element towards this.bounds.first/last

it creates a somewhat more strong coupling between qunit-dom and it being used in Ember, while it is designed to be framework-agnostic

it is relatively easy to pass in this._element (or this.element for the new testing API)

it is rather uncommon to run assertions on the container element, you usually want to assert on the component element that you rendered so this seems like an artificial example

seems unrelated, the this.element in the test harness would still be something
It does (in general) make sense to be able to assert on the rootElement if that rootElement is actually part of the thing being tested.  This does not seem related to Ember to me. 🤔
Totally agreed! And I think that is a perfectly fine resolution here...
It depends on how a host testing system uses the root element.  I'd generally agree with you that it would be better for most involved to use a rootElement that contains the actual contents you are asserting against, rather than asserting against the rootElement itself.

Thanks for chatting this through! I don't feel super strongly, and mostly just wanted to raise the idea to see what y'all thought.  Please close if you'd rather stick to the 3rd bullet above (but we should probably document that as an example in API.md)...

repo: simplabs/qunit-dom


text:
Using too much quota

I'm using simple-youtube-api to perform searches on youtube for music bot, But it's using almost 10k units per 100 requests.
Here's the code:
video = (await youtube.search(music, 1))[0]

That is exactly what you should expect. All search queries use 100 units. https://developers.google.com/youtube/v3/docs/search/list

repo: simple-youtube/simple-youtube-api


text:
Git provider & add badges

Support for:

gitlab
github

usage of namespace in twig missing
migration would be nice
otherwise no objections from me

authors: DavidBadura tolry

repo: simpspector/simpspector


text:
bug fix: handle popstate among networked trajectories while on viewer path

Time estimate or Size
small
Problem
Closes #617
If you are at /viewer hitting back won't actually load the previous trajectory. Same for forward, bug reproduces with local files as well (i.e. navigating back to networked trajectory URL after loading local file).
Solution
Added a new useEffect and handlePopState to useLocationChange
Didn't work with the [location] dependency of previously existing useEffect so made a new one.

I'm assuming this is working code... I had to google popstate event. do we use pushstate events too?

popstate is a type of event, pushState is a method that triggers a popstate event. So yes, we call pushState explicitly in some places, but popstate events can be triggered other ways, like hitting the back button, and this PR is about handling those events more explicitly

repo: simularium/simularium-website


text:
Cannot read property 'start' of undefined (related to babel@6.5.0/1 update)

Here is my file which can't even be "started" since recent a babel update (6.5.1?)
You will not need anything but my file itself to reproduce (I guess the parsing fail somewhere)...
Looks like it's the same kind of issue that just popup here https://github.com/istarkov/babel-plugin-webpack-loaders/issues/15
import test from "ava"; import "babel-core/register"

import feed from "../feed"

test("statinamic/lib/md-collection-loader feed helper", (t) => {

  t.is(
    feed({
      feedOptions: {
        title: "test",
        site_url: "http://statinamic.test/",
      },
      destination: "feed.xml",
      collection: [
        {
          title: "One",
          date: "2015-01-01",
          description: "One",
          __filename: "page/one.md",
          __url: "/page/one/",
        },
        {
          title: "Two",
          date: "2015-12-31",
          description: "Two",
          __filename: "page/two.md",
          __url: "/page/two/",
        },
      ],

      // for testing
      xmlOptions: { indent: "  " },
    }),

    /* eslint-disable max-len */
    `<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">
  <channel>
    <title><![CDATA[test]]></title>
    <description><![CDATA[test]]></description>
    <link>http://statinamic.test/</link>
    <generator>RSS for Node</generator>
    <lastBuildDate>${ (new Date()).toUTCString() }</lastBuildDate>
    <atom:link href="http://statinamic.test/feed.xml" rel="self" type="application/rss+xml"/>
    <item>
      <title><![CDATA[One]]></title>
      <description><![CDATA[One]]></description>
      <link>http://statinamic.test/page/one/</link>
      <guid isPermaLink="true">http://statinamic.test/page/one/</guid>
      <pubDate>Thu, 01 Jan 2015 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title><![CDATA[Two]]></title>
      <description><![CDATA[Two]]></description>
      <link>http://statinamic.test/page/two/</link>
      <guid isPermaLink="true">http://statinamic.test/page/two/</guid>
      <pubDate>Thu, 31 Dec 2015 00:00:00 GMT</pubDate>
    </item>
  </channel>
</rss>`,
    "should generate a feed from a collection"
  )
})

Here a minimal test case
~/Sync/Development
❯ mkd ava-fail

~/Sync/Development/ava-fail
❯ node --version
v5.5.0

~/Sync/Development/ava-fail
❯ npm --version
3.7.1

~/Sync/Development/ava-fail
❯ npm i ava@^0.11.0

~/Sync/Development/ava-fail 3m 43s
❯ pbpaste > fail.js

~/Sync/Development/ava-fail
❯ ava fail.js

TypeError: /Users/MoOx/Sync/Development/ava-fail/fail.js: Cannot read property 'start' of undefined
    at /Users/MoOx/Sync/Development/ava-fail/node_modules/babel-generator/lib/whitespace.js:29:19
    at Whitespace._findToken (/Users/MoOx/Sync/Development/ava-fail/node_modules/babel-generator/lib/whitespace.js:99:30)
    at Whitespace.getNewlinesBefore (/Users/MoOx/Sync/Development/ava-fail/node_modules/babel-generator/lib/whitespace.js:28:22)
    at CodeGenerator.printComment (/Users/MoOx/Sync/Development/ava-fail/node_modules/babel-generator/lib/printer.js:321:34)
    at CodeGenerator.printComments (/Users/MoOx/Sync/Development/ava-fail/node_modules/babel-generator/lib/printer.js:377:12)
    at CodeGenerator.printLeadingComments (/Users/MoOx/Sync/Development/ava-fail/node_modules/babel-generator/lib/printer.js:231:10)
    at CodeGenerator.print (/Users/MoOx/Sync/Development/ava-fail/node_modules/babel-generator/lib/printer.js:81:10)
    at CodeGenerator.printJoin (/Users/MoOx/Sync/Development/ava-fail/node_modules/babel-generator/lib/printer.js:193:12)
    at CodeGenerator.printList (/Users/MoOx/Sync/Development/ava-fail/node_modules/babel-generator/lib/printer.js:258:17)
    at CodeGenerator.ObjectExpression (/Users/MoOx/Sync/Development/ava-fail/node_modules/babel-generator/lib/generators/types.js:48:10)
    at CodeGenerator._print (/Users/MoOx/Sync/Development/ava-fail/node_modules/babel-generator/lib/printer.js:155:17)
    at CodeGenerator.print (/Users/MoOx/Sync/Development/ava-fail/node_modules/babel-generator/lib/printer.js:91:10)
    at CodeGenerator.printJoin (/Users/MoOx/Sync/Development/ava-fail/node_modules/babel-generator/lib/printer.js:193:12)
    at CodeGenerator.printList (/Users/MoOx/Sync/Development/ava-fail/node_modules/babel-generator/lib/printer.js:258:17)
    at CodeGenerator.CallExpression (/Users/MoOx/Sync/Development/ava-fail/node_modules/babel-generator/lib/generators/expressions.js:142:8)
    at CodeGenerator._print (/Users/MoOx/Sync/Development/ava-fail/node_modules/babel-generator/lib/printer.js:155:17)
From previous event:
    at Api.run (/Users/MoOx/Sync/Development/ava-fail/node_modules/ava/api.js:148:4)
    at Object.<anonymous> (/Users/MoOx/Sync/Development/ava-fail/node_modules/ava/cli.js:115:5)
    at Module._compile (module.js:413:34)
    at Object.Module._extensions..js (module.js:422:10)
    at Module.load (module.js:357:32)
    at Function.Module._load (module.js:314:12)
    at Function.Module.runMain (module.js:447:10)
    at startup (node.js:139:18)
    at node.js:999:3

Workaround
import test from "ava"; import "babel-core/register"

import feed from "../feed"

test("statinamic/lib/md-collection-loader feed helper", (t) => {

  const feedXML = feed({
    feedOptions: {
      title: "test",
      site_url: "http://statinamic.test/",
    },
    destination: "feed.xml",
    collection: [
      {
        title: "One",
        date: "2015-01-01",
        description: "One",
        __filename: "page/one.md",
        __url: "/page/one/",
      },
      {
        title: "Two",
        date: "2015-12-31",
        description: "Two",
        __filename: "page/two.md",
        __url: "/page/two/",
      },
    ],

    // for testing
    xmlOptions: { indent: "  " },
  })

  /* eslint-disable max-len */
  const feedXMLexpected = `<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">
  <channel>
    <title><![CDATA[test]]></title>
    <description><![CDATA[test]]></description>
    <link>http://statinamic.test/</link>
    <generator>RSS for Node</generator>
    <lastBuildDate>${ (new Date()).toUTCString() }</lastBuildDate>
    <atom:link href="http://statinamic.test/feed.xml" rel="self" type="application/rss+xml"/>
    <item>
      <title><![CDATA[One]]></title>
      <description><![CDATA[One]]></description>
      <link>http://statinamic.test/page/one/</link>
      <guid isPermaLink="true">http://statinamic.test/page/one/</guid>
      <pubDate>Thu, 01 Jan 2015 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title><![CDATA[Two]]></title>
      <description><![CDATA[Two]]></description>
      <link>http://statinamic.test/page/two/</link>
      <guid isPermaLink="true">http://statinamic.test/page/two/</guid>
      <pubDate>Thu, 31 Dec 2015 00:00:00 GMT</pubDate>
    </item>
  </channel>
</rss>`

  t.is(
    feedXML,
    feedXMLexpected,
    "should generate a feed from a collection"
  )
})

FYI, I am facing this issue on multiple (all?) projects (eg: https://travis-ci.org/postcss/postcss-import/jobs/108972544#L631) poke @hzoo

Looking..
Also a simplier snippet from what you had that fails
import test from "ava";

test("a", t => {
  t.is(
    {
      // for testing
    },
    1
  );
});

If the comment is removed that error is gone.

@hzoo I came to the same conclusion
"fix" for postcss-import: https://github.com/postcss/postcss-import/pull/172

And then fixing that by reverting that PR only lead me to find an acorn error?
hzhu/dev/test/node_modules/power-assert-formatter/node_modules/acorn/dist/acorn.js:945
  throw err;
  ^

SyntaxError: Unexpected token (1:17)
    at Parser.pp.raise (/Users/hzhu/dev/test/node_modules/power-assert-formatter/node_modules/acorn/dist/acorn.js:943:13)
    at Parser.pp.unexpected (/Users/hzhu/dev/test/node_modules/power-assert-formatter/node_modules/acorn/dist/acorn.js:1503:8)
    at Parser.pp.parseIdent (/Users/hzhu/dev/test/node_modules/power-assert-formatter/node_modules/acorn/dist/acorn.js:670:10)
    at Parser.parseIdent (/Users/hzhu/dev/test/node_modules/acorn-es7-plugin/acorn-es7-plugin.js:93:19)
    at Parser.pp.parsePropertyName (/Users/hzhu/dev/test/node_modules/power-assert-formatter/node_modules/acorn/dist/acorn.js:554:127)

Not sure about this

hzhu/dev/test/node_modules/power-assert-formatter/node_modules/acorn/dist/acorn.js:945

@twada Any chance power-assert has something to do with this issue?

@hzoo acorn.input becomes t.is({ // comment }, 1) in your case. Forcing a newline in concise mode at https://github.com/babel/babel/blob/master/packages/babel-generator/src/printer.js#L300 should help.

Related? sindresorhus/xo#79

@sindresorhus Understood. I'll fix babel-plugin-espower ASAP.
Thanks @hzoo @gzzhanghao !

Just released babel-plugin-espower 2.1.2 to fix the problem. Thank you for reporting and suggestions.

@MoOx would you reinstall ava and try again?

@BarryThePenguin Yup.
@twada Thanks for the quick response. That did it for me.

Thanks guys! This is now ok.

authors: BarryThePenguin MoOx gzzhanghao hzoo mastilver sindresorhus twada

repo: sindresorhus/ava


text:
Add Artificial Humour

https://github.com/vadim0x60/awesome-artificial-humour
Artificial Humour is both an interesting scientific field and a fun way to spend a night. Awesome Artificial Humour is probably the best repository on this topic online
By submitting this pull request I confirm I've read and complied with the below requirements 🖖
Please read it multiple times. I spent a lot of time on these guidelines and most people miss a lot.
Requirements for your pull request

Don't waste my time. Do a good job, adhere to all the guidelines, and be responsive.
You have to review at least 2 other open pull requests.
Try to prioritize unreviewed PRs, but you can also add more comments to reviewed PRs. Go through the below list when reviewing. This requirement is meant to help make the Awesome project self-sustaining. Comment here which PRs you reviewed. You're expected to put a good effort into this and to be thorough. Look at previous PR reviews for inspiration. Just commenting “looks good” or simply marking the pull request as approved does not count! You have to actually point out mistakes or improvement suggestions.
You have read and understood the instructions for creating a list.
This pull request has a title in the format Add Name of List.

✅ Add Swift
✅ Add Software Architecture
❌ Update readme.md
❌ Add Awesome Swift
❌ Add swift
❌ add Swift
❌ Adding Swift
❌ Added Swift

Your entry here should include a short description about the project/theme of the list. It should not describe the list itself. The first character should be uppercase and the description should end in a dot. It should be an objective description and not a tagline or marketing blurb.

✅ - [iOS](…) - Mobile operating system for Apple phones and tablets.
✅ - [Framer](…) - Prototyping interactive UI designs.
❌ - [iOS](…) - Resources and tools for iOS development.
❌ - [Framer](…)
❌ - [Framer](…) - prototyping interactive UI designs

Your entry should be added at the bottom of the appropriate category.
The suggested Awesome list complies with the below requirements.

Requirements for your Awesome list

Has been around for at least 30 days.That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent.
Don't open a Draft / WIP pull request while you work on the guidelines. A pull request should be 100% ready and should adhere to all the guidelines when you open it.
Run awesome-lint on your list and fix the reported issues. If there are false-positives or things that cannot/shouldn't be fixed, please report it.
The default branch should be named main, not master.
Includes a succinct description of the project/theme at the top of the readme. (Example)

✅ Mobile operating system for Apple phones and tablets.
✅ Prototyping interactive UI designs.
❌ Resources and tools for iOS development.
❌ Awesome Framer packages and tools.

It's the result of hard work and the best I could possibly produce.
If you have not put in considerable effort into your list, your pull request will be immediately closed.
The repo name of your list should be in lowercase slug format: awesome-name-of-list.

✅ awesome-swift
✅ awesome-web-typography
❌ awesome-Swift
❌ AwesomeWebTypography

The heading title of your list should be in title case format: # Awesome Name of List.

✅ # Awesome Swift
✅ # Awesome Web Typography
❌ # awesome-swift
❌ # AwesomeSwift

Non-generated Markdown file in a GitHub repo.
The repo should have awesome-list & awesome as GitHub topics. I encourage you to add more relevant topics.
Not a duplicate. Please search for existing submissions.
Only has awesome items. Awesome lists are curations of the best, not everything.
Does not contain items that are unmaintained, has archived repo, deprecated, or missing docs. If you really need to include such items, they should be in a separate Markdown file.
Includes a project logo/illustration whenever possible.

Either centered, fullwidth, or placed at the top-right of the readme. (Example)
The image should link to the project website or any relevant website.
The image should be high-DPI. Set it to maximum half the width of the original image.

Entries have a description, unless the title is descriptive enough by itself. It rarely is though.
Includes the Awesome badge.

Should be placed on the right side of the readme heading.

Can be placed centered if the list has a centered graphics header.

Should link back to this list.

Has a Table of Contents section.

Should be named Contents, not Table of Contents.
Should be the first section in the list.
Should only have one level of nested lists, preferably none.
Must not feature Contributing or Footnotes sections.

Has an appropriate license.

We strongly recommend the CC0 license, but any Creative Commons license will work.

Tip: You can quickly add it to your repo by going to this URL: https://github.com/<user>/<repo>/community/license/new?branch=main&template=cc0-1.0 (replace <user> and <repo> accordingly).

A code license like MIT, BSD, Apache, GPL, etc, is not acceptable. Neither are WTFPL and Unlicense.
Place a file named license or LICENSE in the repo root with the license text.
Do not add the license name, text, or a Licence section to the readme. GitHub already shows the license name and link to the full text at the top of the repo.
To verify that you've read all the guidelines, please comment on your pull request with just the word unicorn.

Has contribution guidelines.

The file should be named contributing.md. Casing is up to you.
It can optionally be linked from the readme in a dedicated section titled Contributing, positioned at the top or bottom of the main content.
The section should not appear in the Table of Contents.

All non-important but necessary content (like extra copyright notices, hyperlinks to sources, pointers to expansive content, etc) should be grouped in a Footnotes section at the bottom of the readme. The section should not be present in the Table of Contents.
Has consistent formatting and proper spelling/grammar.

The link and description are separated by a dash. Example: - [AVA](…) - JavaScript test runner.
The description starts with an uppercase character and ends with a period.
Consistent and correct naming. For example, Node.js, not NodeJS or node.js.

Doesn't use hard-wrapping.
Doesn't include a Travis badge.You can still use Travis for list linting, but the badge has no value in the readme.
Doesn't include an Inspired by awesome-foo or Inspired by the Awesome project kinda link at the top of the readme. The Awesome badge is enough.

Go to the top and read it again.

My guess would be the research papers section, which contains some fairly long descriptions.
As far as the ellipsis, you've put three periods in a row. This isn't correct You should enter it directly as "…" using ….

The non-English resources should be in a separate Markdown file. It can be linked to from the readme.

I would try to shorten the paper descriptions.

authors: dgrahn sindresorhus vadim0x60

repo: sindresorhus/awesome


text:
Upgrade Ava 1.4.1 -> 2.1.0

This upgrades Ava to the latest major version.

Travis is failing

That's because Ava does not support Node 6 (I think).
Can Node 6 support be dropped in this module? I can submit a PR for that too.

Done at #25.

authors: ehmicky sindresorhus

repo: sindresorhus/mimic-fn


text:
TypeError: Cannot convert a Symbol value to a string

I am not sure if the Symbol value would be ignored
const { stringify } = require('query-string');

stringify({ a: () => (1), b: Symbol('test') });

module.exports = str => encodeURIComponent(str).replace(/[!'()*]/g, x => `%${x.charCodeAt(0).toString(16).toUpperCase()}`);
                        ^

TypeError: Cannot convert a Symbol value to a string
    at encodeURIComponent (<anonymous>)
    at module.exports (/Users/jesse/workspace/iot-cloud-fe/iot-cloud-util/benchmark/node_modules/_strict-uri-encode@2.0.0@strict-uri-encode/index.js:2:25)
    at encode (/Users/jesse/workspace/iot-cloud-fe/iot-cloud-util/benchmark/node_modules/_query-string@7.0.0@query-string/index.js:188:27)
    at /Users/jesse/workspace/iot-cloud-fe/iot-cloud-util/benchmark/node_modules/_query-string@7.0.0@query-string/index.js:382:39
    at Array.map (<anonymous>)
    at exports.stringify (/Users/jesse/workspace/iot-cloud-fe/iot-cloud-util/benchmark/node_modules/_query-string@7.0.0@query-string/index.js:361:14)
    at Object.<anonymous> (/Users/jesse/workspace/iot-cloud-fe/iot-cloud-util/benchmark/query-string.js:12:1)
    at Module._compile (internal/modules/cjs/loader.js:1063:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1092:10)
    at Module.load (internal/modules/cjs/loader.js:928:32)

These are the supported values: https://github.com/sindresorhus/query-string/blob/20992772758fc74188db64e789535469adaf241f/index.d.ts#L398-L403
I guess we could improve the readme to mention those too, and also throw a more human-friendly error.

@sindresorhus I feel like the Symbol value being ignored that would be better

I disagree. That could hide bugs. I prefer strict type checking. This is also how the browser API works:
new URLSearchParams({foo: Symbol()})
//=> Uncaught TypeError: Cannot convert a Symbol value to a string

@sindresorhus but other packages like qs and querystringify work well if give a Symbol value.

That is not a good argument for doing it.

@sindresorhus anyway, it's up to you

@sindresorhus Yes you were right, Symbol should not be converted to string , from mdn  web docs

We are having a similar issue encodeURIComponent(...).replaceAll is not a function in:
TypeError: encodeURIComponent(...).replaceAll is not a function
  at strictUriEncode(../node_modules/query-string/base.js:8:62)
  at encode(../node_modules/query-string/base.js:256:27)
  at map(../node_modules/query-string/base.js:450:10)
  at Array.map(<anonymous>)
  at stringify(../node_modules/query-string/base.js:429:14)

It's only happening to users on Edge 122. A very strange errror.
The code is:
  const search = queryString.stringify({
    'redirect-to': `${location.pathname}${location.search}`,
  });

authors: RiteshKSingh1709 esetnik fengxinming sindresorhus

repo: sindresorhus/query-string


text:
Execution start time is always in UTC

The execution start time is always in UTC. Was looking in the code and it would be great if we can add support to show the time in current timezone. Its really helpful when you are running builds in multiple windows or trying to figure out when you built the last time.

The reason it's UTC is that a lot of people are running it on build servers around the world and need an absolute time no matter where it is.

sure, but adding a config setting to switch to displaying time in current timezone would be really useful.

Not really interested in adding an option for something that obscure. I'd rather either go with the current way or switch to showing local time with the timezone. Not sure which yet.

I would love to be able to switch time zone!
+1

This would be awesome! +1

:+1:

I also would love to be able to show time based on time zone

Let's go with local time and append the timezone. Best of both worlds.

authors: AdrianoCahete PombaM isupersid kyanite p2media sindresorhus

repo: sindresorhus/time-grunt


text:
[python] Remove no-longer-necessary _query_condition import

Issue and/or context: https://github.com/single-cell-data/TileDB-SOMA/pull/1960#discussion_r1528881351, #2293
Update:

The underlying segfault still exists: #2293; occurs on macOS when tiledb is imported before tiledbsoma
#2299 made it harder to trigger while unit-testing, because it made conftest.py import tiledbsoma very early during test initialization (here)
It's probably safe/reasonable to remove the _query_condition import, as this PR does, since it is no longer helping us work around Typeguard issues or the segfault.

Previous description
If a from tiledbsoma import _query_condition is omitted at the start of tests/__init__.py, tests segfault during clib.SOMAObject.open here:
https://github.com/single-cell-data/TileDB-SOMA/blob/0b99e032dd54028227a0f4d8a3ce025e499c0254/apis/python/src/tiledbsoma/_tdb_handles.py#L56-L60
Currently this PR is just designed to repro the issue.
Update: GHA repro line, appears to be macOS only.

Updated description re: why the _query_condition import is no longer necessary, merging this now.

repo: single-cell-data/TileDB-SOMA


text:
allow class attribute on application node

This PR replaces #154, adding unit tests for the class name.
I changed the commit author to myself so I could sign the commit, but kept @MarcusResell in the co-authored-by since he did all the hard work!

Any progress on this?
Additionally, it looks like we may want to consider having this operate similarly when using <Parcel> elements

@AndrewSGould I will do this when I get the time so that the PR can at least be available

Released in https://github.com/single-spa/single-spa-layout/releases/tag/v2.2.0

Documented in https://github.com/single-spa/single-spa.js.org/pull/586

authors: AndrewSGould jamesarosen joeldenning thejayhaykid

repo: single-spa/single-spa-layout


text:
feat: make create materialized view from source available

What's changed and what's your intention?
This PR fixes the create materialized view from source feature
It is now possible to create materialized views from the rust frontend
However, the state storage of the source executor is not currently handled and requires a PR from @tabVersion  to complete
Since we need to start the whole MV with the first barrier, we modified /src/compute/tests/table_v2_materialize.rs to inject the first barrier
Checklist

[x] I have written necessary docs and comments
[x] I have added necessary unit tests and integration tests

Refer to a related PR or issue link (optional)

Do we have e2e tests?

Do we have e2e tests?

e2e will be available in the next pr

authors: neverchanje shanicky

repo: singularity-data/risingwave


text:
feat(docs): add docs for the relational table layer

What's changed and what's your intention?
As title. I guess the expression needs polishing.
Checklist

[x] I have written necessary docs and comments
[x] I have added necessary unit tests and integration tests
[x] All checks passed in ./risedev check (or alias, ./risedev c)

Refer to a related PR or issue link (optional)
close https://github.com/singularity-data/risingwave/issues/3299

Personally, I have never seen this format... Maybe "stateful" would be good enough?

Just click docs change to review this PR.

... and I think it may worth creating a new docs on relational table. We can leave the An Overview of RisingWave State Store docs to describe only the KV part, and have another Storing State Using Relation Table docs to describe the relational table part.

... and I think it may worth creating a new docs on relational table. We can leave the An Overview of RisingWave State Store docs to describe only the KV part, and have another Storing State Using Relation Table docs to describe the relational table part.

Good Idea!

I think we can also explain the table's properties in this section, and also the vnode part? I believe relational table will have a big upcoming refactor in the near future. Do you want to include the vnode-related things in this docs?

Is vnode part better put in consistence hash doc?

Is vnode part better put in consistence hash doc? @xx01cyx will write a doc to summarize consistence hash soon.

If this doc is to give the detailed encoding, just like
| mv     | table_id \| vnode \| sort key \| pk \| col_id| materialized value |

then maybe there should be a brief description on vnode in this doc. I'm sure we will have a more detailed description on how vnode works in our system in the doc for consistent hash.

After vnode is encoded in keyspace, will add vonde in this form and add link to corresponding doc.

authors: Sunt-ing skyzh wcy-fdu xx01cyx


text:
feat: add tags to recipe

Suggestion:
Make a table for tags, with a column called userId that is nullable. Fill it with default tags, ("Dinner", "Lunch", "Dessert" etc) and set those to userId = null. If a user adds a new tag ("ChristmasParty2024" for example), this tag gets their userId and is only accessible to them.
Question:
Should tags related to a recipe be saved as a string array within the recipe, or should we use a many to many table (recipe_tags)? A string array is easy and might be enough for our needs, but lacks flexibility and scalability. When searching for all recipes with a certain tag ("Find all recipes with the tag "Dinner" for example) the many to many table approach might be more suitable?
Problem:
There will probably be duplicates in the tables. For example if two people create their own "ChristmasParty2024" tag, each will have their own tag entry in the tags table with a unique userId, but the tag name will be the same.

I think a many-to-many relation is a good idea!

I like the many to many as well! And checking for duplicates seems like a good idea, maybe using ON CONFLICT DO NOTHING?
Do we want more info, or just like this:
Tags
CREATE TABLE Tags (
    tag_id SERIAL PRIMARY KEY,
    name VARCHAR(255) UNIQUE NOT NULL
);

RecipeTags (join table)
CREATE TABLE RecipeTags (
    recipe_id INT REFERENCES Recipes(recipe_id) ON DELETE CASCADE,
    tag_id INT REFERENCES Tags(tag_id) ON DELETE CASCADE,
    PRIMARY KEY (recipe_id, tag_id)
);

authors: JoarHansson juliasophieg sirisayshello

repo: sirisayshello/recipe-declutter


text:
Picking etching acid up in bucket and putting back down resets uses counter

Issue: endless etching acid

Since fluid_lib overwrites the default bucket and is required anyway, you could make the fluid node non-removable there based on metadata. This would also have to be applied to pumps so I don't know if its viable. A better idea might a dedicated node that takes etching acid and a single pcb blank.
I also had the idea to make a machine that would create pcb-s automatically, this machine would have an energy buffer, etching acid buffer and an inventory for blanks and an output slot for finished pcbs. This wouldn't replace the original process, however, and would just be an upgrade.

authors: LunaSquee sirrobzeroone

repo: sirrobzeroone/elepower


text:
Limited visibility for the plan

It would be great if there was a modification that would allow you to limit the plan, so as not to load a weak PC a lot of instances
Example:

when placed, the blueprint is shown in its entirety
after placement, the blueprint shows only a few objects, and the rest only after the first ones are built

Or turn on/off the visibility of blueprints with button

Did you try the config option for transparency? You can set that to 100% to make the plan pieces "invisible". Not sure this will help with performance, though.

authors: Vanaheymr sirskunkalot

repo: sirskunkalot/PlanBuild

license: WTFPL


text:
go.mod上的名字有问题？

go: github.com/ansible-semaphore/semaphore/api imports
github.com/Sirupsen/logrus: github.com/Sirupsen/logrus@v1.4.2: parsing go.mod:
module declares its path as: github.com/sirupsen/logrus
but was required as: github.com/Sirupsen/logrus

you need to open an issue in the github.com/ansible-semaphore/semaphore repository.
The import path they are using is incorrect.
it should be github.com/sirupsen/logrus (notice the lower-case s)

@chaser24 did you open an issue at ansible-semaphore/semaphore project for them to update the logrus import path case formatting ?

repo: sirupsen/logrus


text:
DNS Server Monitor Resource

Thank you for providing a Site24x7 Terraform provider.
This PR adds the DNS Server monitor resource. (https://www.site24x7.com/help/api/#dns-server) Data source will be submitted in a separate PR.
Includes:
site24x7_dns_server_monitor resource
Created api.DNSServerMonitor struct for this which uses api.SearchConfig struct for search_config parameter (https://www.site24x7.com/help/api/#dns_search_config) Have updated the relevant terraform resource files to implement this.
Tests
Added dns_server_impl_test.go, client_test.go and dns_server_test.go for testing the resource.
Coverage
Ran make coverage to update coverage.txt to cover new dns server monitor resource.
Documentation Updated relevant documentation to make reference to new resource. Fixed monitor_group_test.go In func TestMonitorGroupCreate, tests were failing with:
--- Expected
+++ Actual
@@ -4,3 +4,3 @@
   Description: "baz",
-  HealthThresholdCount: 0,
+  HealthThresholdCount: 1,
   DependencyResourceIDs: ["234","567"],

I've added HealthThresholdCount:1, to var a (L24) and tests are now passing.

Tagging @jim-billy-zoho for visibility.

@graham-russell  Thank you for your contribution.

Thanks for the review @jim-billy / @jim-billy-zoho - Could you publish the latest version to the Terraform Registry when you have a chance?

Thanks for the review @jim-billy / @jim-billy-zoho - Could you publish the latest version to the Terraform Registry when you have a chance?

We are looking into the issue @graham-russell . Sorry for the inconvenience.

Thanks for the review @jim-billy / @jim-billy-zoho - Could you publish the latest version to the Terraform Registry when you have a chance?

We are looking into the issue @graham-russell . Sorry for the inconvenience.

@graham-russell There was some syncing issue in terraform registry and they have updated the latest version to 1.0.47 now.

authors: graham-russell jim-billy-zoho


text:
weblogic cannot decorate

i use the sitemesh3 in my project，publish to tomcat it's OK， but publish the same war in weblogic，cannot decorate . why ???
after use sitemesh3, in my jsp ${pageContext.request.requestURI} is the jsp path ，not real request path ??? why?
how to solve ???

Well, this looks like an issue with how weblogic decorates it's request. Even if you put your sitemesh filter NOT on FORWARD (the mechanism for retrieving the jsps), the servlet request path will be the JSP path.
I've made a fix for this here #117

If this is still occurring, I can get this resolved for you.
It sounds like FORWARD_SERVLET_PATH is not being set prior to fowarding to the jsp.
Is this still an issue?
Are you at least using servlet API 3.1?

Sounds like this is no longer an issue.  If it is, please open a new ticket and we are more than happy to address it.

authors: Nthalk codeconsole kobe1700


text:
Products not loading while trying to run the project locally

Hi @sivadass
I have downloaded the code for shopping cart app and tried to install it via the create-react-app method, so the webpack and babel files are downloaded automatically.
the set up runs, but i get a lot of warnings and also the products dont get listed.
i have attached a screenshot of the same, kindly help me learn about this.

Thanks!

@suchi-khushi mmm Can you share the screenshot of the Console ?
Surely your problem is a CORS configuration.

authors: estebaninformatica suchi-khushi

repo: sivadass/react-shopping-cart


text:
Plow not working with --body switch

Thanks for your hard work on this but seeking advice about what I believe may be a bug in Windows build version 1.1
Inputting a JSON file into the --body switch fails to copy the contents of the file into the request body of the HTTP command generated by plow
Sample JSON file as follows: (line-endings all in LF format)
{
"test": {
"test_id": "100",
"account_id": "2176db06-dc03-4f21-8de4-de38df531c53",
"funds_balance": "1",
"funds_withheld": "1",
"funds_escrow": "1",
"currency": "thb"
}
}
Expected that these contents will go into the request body of the generated command created by this:
plow http://localhost:4000/api/ -c 1 -n 1 --body @post.json --stream -T 'application/json' -m POST -H "Content-Length:262; Host:localhost:4000"
or this:
plow http://localhost:4000/api/ -c 1 -n 1 --body @post.json --stream -T 'application/json' -m POST
Many thanks. A sample JSON document would be so useful so I can confirm that my JSON document is formatted correctly.

Thanks for you feedback. How did you determine that the --body was not working? Have any detailed information about the test process?

I ran the commands above:
plow http://localhost:4000/api/ -c 1 -n 1 --body @post.json --stream -T 'application/json' -m POST
and
plow http://localhost:4000/api/ -c 1 -n 1 --body @post.json --stream -T 'application/json' -m POST -H "Content-Length:262; Host:localhost:4000"
Localhost:4000 has a Phoenix server and upon inspecting the connection initiated:
%Plug.Conn{   adapter: {Plug.Cowboy.Conn, :...},   assigns: %{},   body_params: %Plug.Conn.Unfetched{aspect: :body_params},   cookies: %{},   halted: false,   host: "localhost",   method: "POST",   owner: #PID<0.1008.0>,   params: %{},   path_info: ["api", "purses"],   path_params: %{},   port: 4000,   private: %{     TestWeb.Router => {[], %{Plug.Swoosh.MailboxPreview => ["mailbox"]}},     :before_send => [#Function<0.23023616/1 in Plug.Telemetry.call/2>],     :phoenix_endpoint => TestWeb.Endpoint,     :phoenix_request_logger => {"request_logger", "request_logger"},     :phoenix_router => TestWeb.Router,     :plug_session_fetch => #Function<1.77458138/1 in Plug.Session.fetch_session/1>,     :raw_version => "application/vnd.td-tp.app.v2+json",     :version => [:v2],     :version_verified => true   },   query_params: %{},   query_string: "",   remote_ip: {127, 0, 0, 1},   req_cookies: %{},   req_headers: [     {Content-Length:262; Host:localhost:4000"},     {"content-type", "'application/json'"},     {"host", "localhost:4000"},     {"user-agent", "plow"}   ],   request_path: "/api/purses",   resp_body: nil,   resp_cookies: %{},   resp_headers: [     {"cache-control", "max-age=0, private, must-revalidate"},     {"x-request-id", "Fty5IL7nWEhsscoAAArD"}   ],   scheme: :http,   script_name: [],   secret_key_base: :...,   state: :unset,   status: nil }
As there is a connection initiated by plow - and the params field is empty (where i expect to see the contents of the JSON file stated above) - there is some grounds to believe that the file is not parsed.
Can kindly advise regarding the format of the JSON file - as there is no documentation with regards to how should it be formatted? For clarity, I have cut and pasted the content of @post.json again:
{ "test": { "test_id": "100", "account_id": "2176db06-dc03-4f21-8de4-de38df531c53", "funds_balance": "1", "funds_withheld": "1", "funds_escrow": "1", "currency": "thb" } }
Many thanks.

Can you achieve that you expected with curl?

curl --location --request POST 'http://localhost:4000/api/purses/' \
--header 'Content-Type: application/json' \
--data-raw '{
    "test": {
        "test_id": "100",
        "account_id": "2176db06-dc03-4f21-8de4-de38df531c53",
        "funds_balance": "1",
        "funds_withheld": "1",
        "funds_escrow": "1",
        "currency": "thb"
    }
}

Hi this cURL command works perfectly. But unfortunately I cannot replicate this using plow
Do you think theres anything wrong w the JSON formatting above? I am on the precompiled plow 1.1.0 on Windows 10. Not using WSL.
Many thanks.

Try remove --stream

I tried that already/again. The result is still the same. :( Appreciate your kind help in this.

Hi @six-ddc did quite a fair bit of testing and managed to make it work.
plow http://localhost:4000/api/ -c 1 -n 1 --body @post.json -T "application/json" -m POST -H "Content-Length:262; Host:localhost:4000"

Do not need to use stream. But it works even with --stream switch
Note that all params need to be enclosed using double quotes on Windows. The single quotes somehow caused the "application/json" parameter to never be passed and no parsing of the JSON is carried out.

TLDR: my bad.
Many thanks.

authors: gaslit six-ddc

repo: six-ddc/plow


text:
Botのprefixを.envファイルで設定すると、末尾の空白が認識されない

デフォルトでは、aria  がprefix となっているが、
BOT_TOKEN=hoge
PREFIX=fuga

と書いたときに、fuga  ではなく fuga が prefix になってしまう。
.env ファイルを読んだ時に、末尾の空白を trim してしまうらしい。

PREFIX="fuga "でいけませんかね？

行けました。
クオートすれば良いことを完全に忘れてました。

repo: sizumita/aria


text:
Fix image resizer occasional hidden when dragging

Fix issue related with https://github.com/sjdemartini/mui-tiptap/issues/211
I moved 'mousdown' state value to the parent and improved selected logic.
I added some comment on the code.
Tested on with both option inline true and false, and it worked fine for me.

I updated missing deps in useEffect.

Can you please merge this change. I need this fix in my application.

repo: sjdemartini/mui-tiptap


text:
change PEP8 to pycodestyle

Hello,
PEP8 linter recently changed its name to pycodestyle :

discussion: https://github.com/PyCQA/pycodestyle/issues/466
commit: https://github.com/PyCQA/pycodestyle/commit/26c64badd9ea27cbfbff311f7b3b09b475e80ead

It causes problems when trying to lint python code:
SKIPPED: pep8 is not installed. Run pip install pep8.

@superzazu @addykim This can be closed, it was changed in the previous commit.

Hello,
The fix for this issue has not been merged (PR #84), the issue is still open

authors: Greums hugovk superzazu

repo: sk-/git-lint


text:
💡[Feature]: Adding Google Authentication using Firebase

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
@sk66641 I want to add Google Authentication using Firebase. Kindly assign this issue to me.
Use Case
Using this feature will allow to login using your gmail account.
Benefits
No response
Add ScreenShots
No response
Priority
High
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

@sk66641 Kindly pls tell wheteher I should start working on this or not?