How to handle the "wildcard" * asterisk on a Windows Command - wordpress

Using
Windows
Local by Flywheel
Composer (task runner)
Working on a Child Theme to a Custom Made "Core" theme.
I'm running composer install on the root of my WP directory to install dependencies on a parent and child theme.
Problem is when the installations are running it errors out when it gets to the src/*.js. I asked the team that set up the page and they told me that it was a problem with how Windows handles wildcard characters, which I understand it as the asterisk* and that they solved it in the pass by getting their employee a Mac. Since these dependencies are not going through, there's files that aren't loading on the website.
Getting a Mac, to solve this issue, is not on the table, so I'm looking to figure out what other options do I have to run this command successfully on a windows?
I tried going directly to the src/ folder and running npx wp-scripts start src on each .js file individually, and it gave a "successful build" message each time, but that didn't fix the issues on the page.
> wp-scripts build src/*.js
assets by status 95 bytes [cached] 2 assets
Entrypoint * = *.js *.asset.php
ERROR in *
Module not found: Error: Can't resolve './src/*.js' in 'C:\Users\UserName\Local Sites\localSiteName\app\public\wp-content\themes\parentThemeName'
resolve './src/*.js' in 'C:\Users\UserName\Local Sites\localSiteName\app\public\wp-content\themes\parentThemeName'
using description file: C:\Users\UserName\Local Sites\localSiteName\app\public\wp-content\themes\parentThemeName\package.json (relative path: .)
Field 'browser' doesn't contain a valid alias configuration
using description file: C:\Users\UserName\Local Sites\localSiteName\app\public\wp-content\themes\parentThemeName\package.json (relative path: ./src/*.js)
no extension
Field 'browser' doesn't contain a valid alias configuration
C:\Users\UserName\Local Sites\localSiteName\app\public\wp-content\themes\parentThemeName\src\*.js doesn't exist
.js
Field 'browser' doesn't contain a valid alias configuration
C:\Users\UserName\Local Sites\localSiteName\app\public\wp-content\themes\parentThemeName\src\*.js.js doesn't exist
.json
Field 'browser' doesn't contain a valid alias configuration
C:\Users\UserName\Local Sites\localSiteName\app\public\wp-content\themes\parentThemeName\src\*.js.json doesn't exist
.wasm
Field 'browser' doesn't contain a valid alias configuration
C:\Users\UserName\Local Sites\localSiteName\app\public\wp-content\themes\parentThemeName\src\*.js.wasm doesn't exist
as directory
C:\Users\UserName\Local Sites\localSiteName\app\public\wp-content\themes\parentThemeName\src\*.js doesn't exist
webpack 5.64.1 compiled with 1 error in 149 ms
Script cd wp-content/themes/parentThemeName && npm install && npm run build && composer install --no-interaction --ansi --ignore-platform-reqs handling the install-core-deps event returned with error code 1
Script composer install-core-deps && composer install-child-deps handling the post-install-cmd event returned with error code 1
Thanks for any and all help.
Cheers!

Related

Nuxt3 deployment with Cloudflare pages failed

I have successfully compiled my nuxt3 project locally. But the deployment is not working with cloud flare page
00:14:35.140 Executing user command: npm run generate
00:14:35.613
00:14:35.613 > generate
00:14:35.613 > nuxt generate
00:14:35.614
00:14:35.725 Nuxt CLI v3.0.0-rc.3-27567768.c1f728e
00:14:38.919 ✔ Using ~/components/content for components in Markdown
00:14:43.437 ℹ Vite client warmed up in 3072ms
00:14:44.646 ℹ Client built in 4280ms
00:14:44.681 ℹ Building server...
00:14:47.053 ✔ Server built in 2373ms
00:14:47.249 ✔ Generated public dist
00:14:47.249 ℹ Initializing prerenderer
00:14:50.871 ℹ Prerendering 4 initial routes with crawler
00:14:50.891 ├─ / (20ms)
00:14:50.894 ├─ /200 (3ms)
00:14:50.897 ├─ /404 (3ms)
00:14:50.958 ├─ /api/_content/cache (61ms)
00:14:50.971 ✔ You can now deploy .output/public to any static hosting!
00:14:51.017 Finished
00:14:51.018 Note: No functions dir at /functions found. Skipping.
00:14:51.018 Validating asset output directory
00:14:51.018 Error: Output directory ".output/public" not found.
00:14:52.095 Failed: build output directory not found
This is failed with "Error: Output directory ".output/public" not found." but actually the directory is generated few lines before. Any clue to resolve this problem?
I worked around the problem with:
Adding Nitro output config [1] [2] to nuxt.config.ts:
export default defineNuxtConfig({
"nitro": {
"output": {
dir: 'output',
serverDir: 'output/server',
publicDir: 'output/public'
}
}
})
In Cloudflare Pages, setting build output directory to: server/output/public.
I think the issue is caused by the default deployment script at CloudFlare side, checking the existence of .output, but not being able to see "hidden" (starting with dot) folders.
17:27:08.682 Validating asset output directory
17:27:08.682 Error: Output directory ".output/public" not found.
Edit (2022-07-10) found a cleaner way:
add "target" : "static" to nuxt.config.ts
Use as CloudFlare Pages build command: ./node_modules/.bin/nuxt generate
Set CloudFlare Pages build output directory to dist
I also had this issue, after testings, this is what i found.
The documentation says Use the nuxi generate command to build your application. (https://v3.nuxtjs.org/getting-started/deployment#static-hosting).
Configure Node Version
First, i'll add an .nvmrc file at the root of the project, so that Cloudflare doesn't use its default 12.18.0 version on deploy.
The content of the file is :
16
sources:
nuxt 3 prerequisites : https://v3.nuxtjs.org/getting-started/installation/#prerequisites
Node version on Cloudflare Pages : https://developers.cloudflare.com/pages/platform/build-configuration/#language-support-and-tools
Configure the Cloudflare Page
Then i'm adding the configuration in the cloudflare interface with following :
Build command: npx nuxi generate
Build output directory: /.output/public
Root directory: /
🚀
Going further
Actually, it shouldn't be a problem to deploy easily on CF Pages: the team has added a cloudflare_pages preset right into nitro, the server library behind nuxt 3. https://nitro.unjs.io/deploy/providers/cloudflare#cloudflare-pages
I wasn't able to make this preset work for now, i'll update my answer when this has changed :)

Upgraded Drush 8 to 9 Site Alias Not Working

I moved from using Docksal to Acquia ADS (Lando) which automatically upgraded my Drush from 8 to 9. My local site works fine but I can't get Drush 9 to "see" my Drupal 8 site. The aliases seem to have been created and added to the drush/sites folder and running drush site:alias does show them. However running drush status shows my Drupal root as /app. My Drupal root is /app/docroot. My alias files do have this as their root (for local). I'm not sure why Drush doesn't use the alias files it knows about. I've tried:
drush #self(or #local) list and I get some commands and this statement at the end:
[NOTE] Drupal root not found. Pass --root or a #siteAlias in order to see Drupal-specific commands.
Doing drush #local(or #self) cr returns:
In BootstrapHook.php line 32: Bootstrap failed. Run your command
with -vvv for more information.
With -vvv:
Exception trace: at
/app/vendor/drush/drush/src/Boot/BootstrapHook.php:32
Drush\Boot\BootstrapHook->initialize() at
/app/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php:34
Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->callInitializeHook()
at
/app/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php:27
Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->initialize()
at
/app/vendor/consolidation/annotated-command/src/CommandProcessor.php:145
Consolidation\AnnotatedCommand\CommandProcessor->initializeHook() at
/app/vendor/consolidation/annotated-command/src/AnnotatedCommand.php:289
Consolidation\AnnotatedCommand\AnnotatedCommand->initialize() at
/app/vendor/symfony/console/Command/Command.php:221
Symfony\Component\Console\Command\Command->run() at
/app/vendor/symfony/console/Application.php:1005
Symfony\Component\Console\Application->doRunCommand() at
/app/vendor/symfony/console/Application.php:255
Symfony\Component\Console\Application->doRun() at
/app/vendor/symfony/console/Application.php:148
Symfony\Component\Console\Application->run() at
/app/vendor/drush/drush/src/Runtime/Runtime.php:118
Drush\Runtime\Runtime->doRun() at
/app/vendor/drush/drush/src/Runtime/Runtime.php:49
Drush\Runtime\Runtime->run() at /app/vendor/drush/drush/drush.php:72
require() at /app/vendor/drush/drush/drush:4
drush status:
PHP binary : /usr/local/bin/php
PHP config :
PHP OS : Linux
Drush script : /app/vendor/drush/drush/drush
Drush version : 10.2.2 <-- Had 9.0.0 but currently trying 10, same issue
Drush temp : /tmp
Drush configs : /root/.drush/drush.yml
/app/vendor/drush/drush/drush.yml
/app/drush/drush.yml
Drupal root : /app
self.site.yml:
local:
root: /app/docroot
uri: example.lndo.site
Can someone please point me in the right direction?
Figured it out. No matter how many ways you try to tell Drush where to look to find your Drupal root, none of it will matter until you edit your composer.json file. Turns out the key to making Drush 9+ work is changing the name in composer.
My composer.json file name went from:
"name": "drupal/drupal",
to:
"name": "drupal-composer/drupal-project",
I don't think this feature was documented anywhere so I'm posting it here in response to my own question in case this helps anyone else.
I realize that this is an older question, however with Drupal 8 recently reaching end of life, and the high probability of many people (like myself) scrambling to upgrade now that clients have realized the risks of using EOL software, I want to take a moment to explain why #r00t's answer works.
r00t is correct that changing the "name" value in composer.json fixed the issue, however, the value that is set is not limited to drupal-composer/drupal-project. This seems to stem from the package webflo/drupal-finder and the way it works.
webflow/drupal-finder is a requirement of drush/drush, so it's going to be included even if you haven't added it manually. It's also a requirement of a couple of others that you may or may not have installed, like palantirnet/drupal-rector (which as a side note, is really helpful for this upgrade).
Within the code for drupal-finder is a method that looks for the install path of Drupal core based on a few items within your composer.json file.
Here is the code from DrupalFinder::isValidRoot()
foreach ($json['extra']['installer-paths'] as $install_path => $items) {
if (in_array('type:drupal-core', $items) ||
in_array('drupal/core', $items) ||
in_array('drupal/drupal', $items)) {
$this->composerRoot = $path;
// #todo: Remove this magic and detect the major version instead.
if (($install_path == 'core') || ((isset($json['name'])) && ($json['name'] == 'drupal/drupal'))) {
$install_path = '';
} elseif (substr($install_path, -5) == '/core') {
$install_path = substr($install_path, 0, -5);
}
....
Which is telling drupal-finder that if the "name" value is drupal/drupal then the install path of the site is at the base of the project, however if it is not drupal/drupal then use a value from extra.installer-paths to find the site install.
I'm still not aware if this is documented anywhere on either webflo/drupal-finder or in drush/drush, but understanding why it was an issue helped me out tremendously.
TL;DR:
If your site's docroot lives next to your vendor folder, change the name in composer.json to anything that isn't drupal/drupal. If your vendor folder lives inside your docroot, drupal/drupal will work for you.

Symfony2 Re-organization config files : parameters.dist.yml issue

I've followed document to re organize files in app/config directory.
Now I have config/common (with config, parameters, parameters.dist, routing, security & services files), and files for each environment in specific directories : app/config/dev and app/config/prod.
But now, when I try to send "composer -n install" to update autoload, I have this error :
[InvalidArgumentException]
The dist file "app/config/parameters.yml.dist" does not exist.
Check your dist-file config or create it.
I know this is a configuration problem, Symfony search my dist file in app/config, how can I redirect it to app/config/common ?
I don't know where is the "dist-file config" written in error.
Thanks!
Found !
It is in composer.json:
under "extra", "incenteev-parameters", I've changed value of "file".

Issue with custome moduel installation in Sulu Admin

I have integrated the Example module in my Sulu-standard installation. The code I used for the example module is from following repository :
https://github.com/sulu/ExampleNewsBundle
And the steps I followed for integration are from this
http://blog.sulu.io/how-to-develop-a-bundle-in-the-sulu-admin-1
After the installation I am getting this error while loading the JS for the module :
"NetworkError: 404 Not Found - http://beauty_dev.com/en/bundles/examplenews/js/main.js?v=develop"
Error: Script error for: /bundles/examplenews/js/main.js http://requirejs.org/docs/errors.html#scripterror
var e = new Error(msg + '\nhttp://requirejs.org/docs/errors.html#' + id);
Error: Script error for: /bundles/examplenews/js/main.js http://requirejs.org/docs/errors.html#scripterror
var e = new Error(msg + '\nhttp://requirejs.org/docs/errors.html#' + id);
After some research I found that 404 error was due to locale(en) appended in the URL.
Is it possible to remove the locale from the URL?
Any reference will be appreciated.
After adding a new bundle you have to reinstall the assets using the following command:
app/console assets:install --symlink
Symfony doesn't do that automatically, so you have to execute this line, in order for the files to be copied to the web directory. You could also check if the accessed file is available in the web directory, which should be the case after executing the above command.
Regarding the language: You see that because Sulu tries to redirect to the default language if the current URL leads to a 404 and doesn't contain a language.
Are you sure that the files in the web/bundles/examplenews folder exists and you can access from the browser? When the files exists and the webserver returns them correctly the /de will not be prepended.

Symfony2 Composer install calls wrong php installation/version internally

I'm trying to set up Symfony 2.5 via Composer.
First I am calling:
php5.3.8-cli /kunden/81425/composer.phar create-project symfony/framework-standard-edition hhcadm/ "2.5.*"
This works until at some point it is internally not calling php5.3.8-cli anymore but somehow uses php. The problem is that php is version 4.4.9 and this causes following effect:
Nothing to install or update
Generating autoload files
Updating the "app/config/parameters.yml" file
X-Powered-By: PHP/4.4.9
Content-type: text/html
<br />
<b>Parse error</b>: syntax error, unexpected T_STRING, expecting T_CONSTANT_ENCAPSED_STRING or '(' in <b>/kunden/81425/hhcadm/vendor/sensio/distribution-bundle/Sensio/Bundle/DistributionBundle/Resources/bin/build_bootstrap.php</b> on line <b>13</b><br />
Script Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::buildBootstrap handling the post-install-cmd event terminated with an exception
[RuntimeException]
An error occurred when generating the bootstrap file.
The error makes sense as 4.4.9 is too old. How can I tell Composer/Symfony installer which php installation to use during the install routine?
Same happens for me when I call:
php5.3.8-cli /kunden/81425/composer.phar install
I am pretty shure there must be a config / param for that but I can't find it for hours now.
Thank you very much.
'php' must be the PHP5 executable.
The only solution i see is to modify the PATH, launch the composer command (and eventually restore the old path)
For example :
OLDPATH=$PATH
PATH=/usr/local/php5/bin:$PATH
php /kunden/81425/composer.phar install
PATH=$OLDPATH
To help you, you can also create a small script 'composer.sh' :
#!/bin/sh
OLDPATH=$PATH
PATH=/usr/local/php5/bin:$PATH
php /kunden/81425/composer.phar $*
PATH=$OLDPATH
And you call 'composer.sh install'
Edit : if all php binaries are in the same, you can create symbolic links
For example :
mkdir /usr/local/bin/php5
ln -s /usr/local/bin/php53-cli /usr/local/bin/php5/php
And so PATH=$PATH:/usr/local/bin/php5:$PATH
Edit: If you are not allowed to create /usr/local/bin/php5 then just use any other folder like:
#!/bin/sh
OLDPATH=$PATH
PATH=/kunden/81425/php5:$PATH
php /kunden/81425/composer.phar $*
PATH=$OLDPATH

Resources