gargsuchi → credited sime → .
gargsuchi → credited sime → .
Marked https://www.drupal.org/project/civictheme/issues/3475985 🐛 No remote media displayed for field_c_p_attachments Active as a duplicate.
I acknowledge it's potentially tricky btw. It was convenient to remove extra classes at some point, and maybe adding them back will introduce regressions.
It's a module available in govcms.
I believe this issue is related.
I put in a steps to reproduce to try to capture what might be going wrong in the real world. Note that removing these cached credentials wassn't altogether easy for me in Firefox without having to apply a broad brush and remove a lot of history and credentials
I think it's crucial in a highly abstracted setup. The editor does not always know where content is coming from.
Thanks Fiona. I'm happy with you setting priority, as long as there is some engagement about it and I can point clients to the status.
I'm just going to put this on hold. Form is currently working according to reports....
This is why contextual links are broken right? Not sure if you just want to fix contextual links over here 🐛 Contextual links are broken Needs work . Or stop removing attributes here. But something should be done.
Any update on this? The Drupal editing experience is super broken.
Left position is better, but not sure if this is a regression. MR-459 patch tested.
It's your project! - however you like is fine. I didn't know if you changed it because you thought it was already fixed in 1.8.
Is this the issue about getting the contextual edit links to work? I recall we discussed it but I'm not sure if i need to create a new issue for it.
You will forward patch this to 1.8? Usualy it gets fixed in main and then backported?
Sorry about that.
I believe that people who want to start working on drupal core have to make some decisions about what sort of work they want to do and what workflows suit that. I therefore think .ddev/config.yaml
is too easy as it assumes those decisions are inconsequential. have talked a lot with @rkoller about the difference between justafish/ddev-drupal-core-dev
and joachim-n/drupal-core-development-project
as the both enable similar outcomes but the work area is different.
BTW I've tried to write up some of this into the canvas of the #ddev-for-core-dev Slack channel, which is a space for people to talk about these decisions and workflows.
I think the flex points that DDEV is supplying to different developers with different workflows are important.
so that a contributor only has to type ddev start and start working?
ddev start
For me this would replace:
ddev config --omit-containers=db --disable-settings-management
ddev start
ddev get justafish/ddev-drupal-core-dev
ddev restart
But for @quietone this replaces something different, I'm reading.
I think you misunderstand me, it looks like your demo is connected to OpenAI. Project Browser wouldn't do that out of the box.
Do any of these integrations you work with allow you to embed a "small gpt" and avoid connecting to commercial services?
@mindaugasd love the examples, but i think the API integration is just not going to happen within the actual Project Browser code base.
@chris - I intentionally tried to keep the title loose. There is a tendency for people to say "plug in to Open AI" but I don't think integration into a commercial service is the way to go and a lot of the drupal modules I've seen are basically doing just that. But it would be silly not to have a place to discuss ideas.
Oh nice!
I can't speak for the extra data fields, I would love to hear an example of using the updated date on a card (which is the default being used here) - it's always interesting to learn about different requirements.
This is all really the job of entity bundle classes, but fwiw i've changed the theme to do this to get the created time.
I needed to add (int) because getCreatedTime() returns timestamp as a string.
* Pre-process for Date node field.
*/
function _civictheme_preprocess_paragraph__node_field__date(array &$variables): void {
if ($node) {
- $variables['date'] = civictheme_format_datetime($node->getChangedTime(), 'civictheme_short_date');
- $variables['date_iso'] = civictheme_format_datetime_iso($node->getChangedTime());
+ $variables['date'] = civictheme_format_datetime((int) $node->getCreatedTime(), 'civictheme_short_date');
+ $variables['date_iso'] = civictheme_format_datetime_iso((int) $node->getCreatedTime());
}
}
I'm not sure if the date should be selectable but it definitely shouldn't use the "changed date" for promo cards, it should use the date created.
griffynh → credited sime → .
Great progress! I feel very supported on this itch :)
Still needs a test to test clearing the cache on PreApplyEvent
sime → changed the visibility of the branch 3451863-cache-validate-pm to hidden.
This is identical to previously committed. I assume i messed up a rebase.
https://git.drupalcode.org/project/project_browser/-/commit/7a04045d3759...
sime → changed the visibility of the branch 3455220-resolve-technical-debt to hidden.
sime → changed the visibility of the branch 3455220-resolve-technical-debt to hidden.
Sorry it appears i migth ahve readded this in a rebase
What was removed
https://git.drupalcode.org/project/project_browser/-/merge_requests/517/...
But it's still there.
https://git.drupalcode.org/project/project_browser/-/blob/2.0.x/tests/sr...
Specifically the model i like about civictheme is the UI Kit implementation with Storybook. However since experience builder will use SDC isn't there an SDC native design system technique we would be using?
> @sime can you help with number 3 in comment #27 for the off-focus/onBlur in Svelte. We just want to close the dropdown on click outside. Thank you.
I had a look and I got close, but I'm not experienced enough in Svelte to do this.
sime → changed the visibility of the branch 3318817-change-catfilter to hidden.
Going to assume we're on 2.x
> Is it possible there is something else causing the performance issues? ... Project Browser is by no means unusable, even with the slow status checks.
I agree it's within the bounds of being ok in "normal" circumstances. This is off course true, since no one thought it was a problem... One thing that slows things down is slow file I/O - there seems to be a lot of checks of the file system. What do you think that will be like with WebAssembly?
> the issue summary says we're running the status check on every page
I found that it was running when I was looking at project detail pages, which is most of the routes you can explore - did you not find this?
Btw. my main goal so far was to demonstrate for myself (and prove to others) that the browsing expereince was significantly improved with caching. So I'm not really wedded to *how* the caching should work and I was mainly waiting to see how the message improvemnet issue landed because it was calling the validation check.
Ya know, I think this is RTBC. Feels solid to me. Will let Chris have the final say.
For anyone who wants to manually test this, a simple way is to install the project_browser_test module.
1. You need this in your settings.php, note that it will start showing test modules/themes in the UI.
$settings['extension_discovery_scan_tests'] = TRUE;
2. Then install project_browser_test, I just use drush.
3. Now in TestInstallerReadiness.php in the statusCheck method, just change the code to manual create whatever messages you want to create.
Re #2, InstallerControllerTest often calls routes like `admin/modules/project_browser/install-begin/drupalorg_mockapi/awesome_module` and this triggers status checks which can time out. I believe.
I analysed the events that PM provides using xhprof, and the StatusCheck event is by far the only event where significant amount of time is spent in our tests, which specifally is any tests where:
- Package Manager is installed
- drupalGet('admin/modules/browse')
.
This is the same as 📌 Too slow to validatePackageManager() on every page Needs review but obviously the solutions will differ. I've created an MR to try @phenaproxima's suggestion in Slack which is to put an event first and then stop propagation.
For the record these are the events subscriber that are running when the test his /admin/modules/browse where the vast majority of time is spent:
- Drupal\package_manager\Validator\ComposerValidator::validate
- Drupal\package_manager\Validator\DiskSpaceValidator::validate
- Drupal\package_manager\Validator\WritableFileSystemValidator::validate
- Drupal\package_manager\Validator\MultisiteValidator::validate
- Drupal\package_manager\Validator\SymlinkValidator::validate
- Drupal\package_manager\Validator\StageNotInActiveValidator::validate
- Drupal\package_manager\Validator\BaseRequirementsFulfilledValidator::validate
- Drupal\package_manager\Validator\PendingUpdatesValidator::validate
- Drupal\package_manager\Validator\LockFileValidator::validate
- Drupal\package_manager\Validator\AllowedScaffoldPackagesValidator::validate
- Drupal\package_manager\Validator\StagedDBUpdateValidator::checkForStagedDatabaseUpdates
- Drupal\package_manager\PathExcluder\UnknownPathExcluder::logExcludedPaths
- Drupal\package_manager\Validator\SettingsValidator::validate
- Drupal\package_manager\Validator\RsyncValidator::validate
- Drupal\package_manager\Validator\ComposerPluginsValidator::validate
- Drupal\package_manager\Validator\ComposerPatchesValidator::validate
- Drupal\package_manager\Validator\PhpExtensionsValidator::validateXdebug
- Drupal\package_manager\Validator\PhpExtensionsValidator::validateOpenSsl
Changes I made result in this:
The worst case scenario is two messages of the same type, thus showing the same prefix, but I think this is acceptable as it's very rare and looks fine.
I'm just going to combined these up a little. It would be rare to have multiple errors here, I believe, so we'll just prefix each one and skip the extra ones?
Thanks @phenaproxima! Satisfying nit.
Everything checks out :thumbsup:
Thanks for the guidance!
sime → changed the visibility of the branch 3322594-DrupalConPortland2024-snapshot-1x to hidden.
sime → changed the visibility of the branch 3322594-DrupalConPortland2024-snapshot-1x to hidden.
@phenaproxima has tightened the scope and it is looking good to me. I like the improvements in variable handling.
I have created a few extra tickets out of the things I learnt in the course of working on it.
📌
Resolve technical debt in initPackageManager()
Active
📌
ServiceProviderBase::alter shouldn't call parent::register
Active
📌
Identify and action solutions for flaky tests
Active
Before i forget, Chris wanted to be sure that this code was aligned with how AU/PM handles caching of this same data. That was going to be something I looked at after 📌 Do not prevent UI install for PM warnings Needs review .
And it would be so easy to swap KV with something else if needed later.
Everything else makes sense and it's worth a maintainer having a look - the key thing I see is changes to how the projects are uniquely identified and then all the services are adjusted to support that.