elabx

Ohh I hadn't understand this about WSL! So it's a case of docker inside docker? Interesting!

From how I understand it docker just doesn't know anything about the symlink if it's coming from the host, as if it's not even there. I think a way to confirm this assumption would be to ddev ssh, and navigate to htdocs, should be empty or with odd permissions? I use this trick to load composer libraries locally, but keeping them all in a central part of my host computer, I have a post about this somewhere around this thread.

Maybe you could try with volume mounting? This in .ddev/docker-compose.htdocs-volume.yaml https://stackoverflow.com/questions/57426306/ddev-mount-additional-folders-for-shared-composer-packages/57432155#57432155 services: web: volumes: - "/mnt/c/Users/brendonkoz/Dropbox/development/htdocs:/var/www/html/htdocs"

Snapshot of the moment, got a Mac Studio with 64GB of ram and running around 8-10 projects everything goes smooth. Got the docker provider using around 16GB of memory. I do this too, but I don't auto run it on login. I can see how this could be a bottleneck, I don't think it's unbearable to start every project when needed since like you mention, you actively work in a few of them. With your 128GB of ram I'd definitely give it a shot because yolo haha. "ddev start --all" let's go!

Can you try disabling FileCompiler for files in templates?? Or I'm just seeing the logNotices options, maybe that? /** * File compiler options (as used by FileCompiler class) * * Enables modification of file compiler behaviors. See also $config->moduleCompile * and $config->templateCompile settings. * * #property bool siteOnly Specify true to prevent compiler from attempting compilation outside files in /site/ (default=false). * #property bool showNotices Show notices in admin about compiled files to superuser when logged in (default=true). * #property bool logNotices Log notices about compiled files and maintenance to file-compiler.txt log (default=true). * #property string chmodFile Mode to use for created files, i.e. "0644" (uses $config->chmodFile setting by default). * #property string chmodDir Mode to use for created dirs, i.e. "0755" (uses $config->chmodDir setting by default). * #property array exclusions Exclude paths that exist within any of these paths (default includes $config->paths->wire). * #property array extensions File extensions that we compile (default=php, module, inc). * #property string cachePath Path where compiled files are stored (default is $config->paths->cache . 'FileCompiler/') * * @var array * */ $config->fileCompilerOptions = array( 'siteOnly' => false, // only allow compilation of files in /site/ directory 'showNotices' => true, // show notices about compiled files to superuser when logged in 'logNotices' => true, // log notices about compiled files and maintenance to file-compiler.txt log. 'chmodFile' => '', // mode to use for created files, i.e. "0644" 'chmodDir' => '', // mode to use for created directories, i.e. "0755" 'exclusions' => array(), // exclude filenames or paths that start with any of these 'extensions' => array('php', 'module', 'inc'), // file extensions we compile 'cachePath' => '', // path where compiled files are stored, or blank for $config->paths->cache . 'FileCompiler/' );

Exactly!

I think Media Manager is in the process of being open sourced? I think this is a module worth polishing and it's the closest to a media manager solution I can think of.

The new ProcessWire theme seems have lost the darkened backgorund of the fieldsets? Is this intentional? vs:

got this feel too! better if you can zip and unzip on server.

I have to try this module next week and remove my monstrous hooks, fantastic @Robin S, thanks!

I did a very weird hook using InputfieldImage::renderAdditionalFields and adding a nested hook that happens only once and removes all fields of any InputfieldWrapper before it renders. Tbh now looking at this doesn't seem like the best option 😕 It'd be clenaer if this method was hookable.

$wire->addHookBefore('ProcessPageList::execute', function ($event) { $event->object->addHookAfter("find", function ($e) { $selector = $e->arguments(0); $page = $e->arguments(1); if ($page->template == "blog") { $selector = new Selectors($selector); $selector->add(new SelectorEqual('sort', '-sticky')); $selector->add(new SelectorEqual('sort', $page->sortfield())); $result = $page->children($selector); $e->return = $result; } }); }); I think this is it, I remember the other caveat now, that "-sticky" is a checkbox field added to the pages I want on top. Also not super sure the nested hook is required, maybe just hook before/after "ProcessPageList::find".

15 years laters! Thanks for the code snippet! Cannot execute I module I created since it has "permission" option enabled.

Indeed, looking fine again.

Saw it here too: https://processwire.com/api/ref/module/ Maybe it's part due to the site being updated soon? Since this is recent, I was jus reading this docs yesterday.

Does content.php have namespaces? I also randomly sometimes get these errors, I think it has something to do with the ProcessWire FileCompiler, using namespaces everywhere reduces the chance of this happening.

Has anyone experienced issues with Issue vite, Less and data-uris being converted to relative paths instead of inline SVGs? pretty much like done here: https://github.com/uikit/uikit/blob/main/src/less/components/mixin.less The issue is pretty much explained in this pull request on the vite code base that is supposed to be solved: https://github.com/vitejs/vite/pull/7400/files#diff-2cfbd4f4d8c32727cd8e1a561cffbde0b384a3ce0789340440e144f9d64c10f6 Has anyone figured out if there is a configuration needed in vite to make these work? Here goes my vite.config.js fwiw: import { defineConfig } from 'vite'; import { fileURLToPath } from 'url'; import { basename, resolve} from 'path'; import removeConsole from "vite-plugin-remove-console"; import FullReload from 'vite-plugin-full-reload' const ASSET_URL = process.env.NODE_ENV == 'production' ? '/site/templates/assets/dist' : ''; const port = 5173; const origin = `${process.env.DDEV_PRIMARY_URL}:${port}`; export default defineConfig({ base: ASSET_URL, resolve: { alias: { '../../images/backgrounds': 'uikit/src/images/backgrounds', '../../images/components': 'uikit/src/images/components', '../../images/icons': 'uikit/src/images/icons' } }, build: { minify: true, manifest: true, rollupOptions: { input: { build: resolve(__dirname, './main.js'), }, output: { manualChunks: { uikitjs: ['uikit/dist/js/uikit', 'uikit/dist/js/uikit-icons-custom.js'] }, entryFileNames: `[name].js`, chunkFileNames: `[name].js`, assetFileNames: `[name].[ext]` } } }, plugins: [ removeConsole(), FullReload([ '../../**/*.php' ]), ], css: { devSourcemap:true, preprocessorOptions: { less: { math: 'parens-division' } } }, server: { cors: { origin: 'https://somedomain.ddev.site' }, host: '0.0.0.0', port: port, strictPort: true, // Defines the origin of the generated asset URLs during development origin: origin } })

I like Runcloud/Ploi.

On the "Settings specific to Page Auto Complete", can you add the field "notes", to the search fields? Also I would try on selector string of the Selectable page soptions removing the "title|notes%=query", since this would not seem what you want? Otherwise only pages with the word "query" on the notes field would be selectable. template=paclage, sort=title

@adrian@adriana bit more of this odd behaviour where fields disappear from templates, also as misterious as our own (@adrian's and myself) experiences.

You can do this with the $buster API

Skeumorphism is so back! Ask Airbnb crew! /j

I'd say very unlikely.

Could you check if there is a field that no longer exists in the backend but is being indicated as editable in the FrontendEdit?? Like, say you deleted 'text' field and now you are trying to call <edit field="text"></edit> At least this is what I get from reading the source of PageFrontEdit.module, but I don't use this module much.

I am a big UIkit user too so I might be biased but I kind of share this sentiment! Maybe something we could work out as a community it to have a clear pathway to handle UI in the admin, so in order of "theming relevance" (?) have something in the docs that explain this pathway: jQuery UI CSS UIKit Less compiling of its theme (eg. keeping the UIkit's flavor of dark mode to keep the rest of components that are not used in the core admin UIs) ProcessWire theme CSS variables Aside from the visual nuances, I think having this part as organized as we can will benefit us all since all parts are useful in their own way! Then again, thanks for all the work put into this!