10up / generator-wp-make Goto Github PK

I've gone through the process of making several test plugins and its only this prompt that repeats.

I was getting this error with default Gruntfile.js during grunt build process. Found out you need to add expand: true to the copy task:

copy: {
   main: {
      src: [....],
      dest: '...',
      expand: true
   }
}

When I run grunt build in a wp-make theme the copy task fails:

Andis-iMac:akbyte Andi$ grunt build
Running "sass:all" (sass) task

Running "postcss:dist" (postcss) task
>> 1 processed stylesheet created.

Running "cssmin:minify" (cssmin) task
>> 1 file created. 148.03 kB → 114.64 kB

Running "jshint:all" (jshint) task
>> 2 files lint free.

Running "concat:main" (concat) task
File assets/js/akbyte.js created.

Running "uglify:all" (uglify) task
>> 1 file created.

Running "clean:main" (clean) task
>> 0 paths cleaned.

Running "copy:main" (copy) task
Warning: Unable to write "release/preview/assets" file (Error code: EISDIR). Use --force to continue.

Aborted due to warnings.

This generator lacks proper unit tests currently. It should probably have them.

So this discussion came up in a chat a while ago, apparently .dev is a real domain owned by google, however it's default when using wp-make... should we change it to be .local which is reserved for local environments?

Hi,

I installed plugin using wp-make (with autoprefixed and without sass) as per the instructions in the readme file and got following issues:

1. bower.json:5 has an extra brace.
2. While running "grunt" task, I got following warning:
   "No postcss targets found".

the /tasks dir is specific to Grunt, and I imagine would have no need in a build/release version.

You should be able to run grunt test to invoke both the PHPUnit and QUnit tests, but they are both failing in the current setup on a fresh plugin install. PHP Unit doesn't run any tests and QUnit is failing to run.

First bootstrap.php was changed to bootstrap.php.dist. I updated the generated Gruntfile.js ang got the following:

$ grunt test
Running "phpunit:classes" (phpunit) task
Starting phpunit (target: classes) in tests/phpunit/
PHPUnit 4.5.0 by Sebastian Bergmann and contributors.

Configuration read from /Users/Luke/Desktop/test-plugin/phpunit.xml.dist



Time: 115 ms, Memory: 8.00Mb

No tests executed!

Running "qunit:all" (qunit) task
Testing tests/qunit/my-plugin.html 
>> PhantomJS timed out, possibly due to a missing QUnit start() call.
Warning: 1/1 assertions failed (0ms) Use --force to continue.

Aborted due to warnings.
Beast-Pro:test-plugin Luke$ grunt test
Running "phpunit:classes" (phpunit) task
Starting phpunit (target: classes) in tests/phpunit/
PHPUnit 4.5.0 by Sebastian Bergmann and contributors.

Configuration read from /Users/Luke/Desktop/test-plugin/phpunit.xml.dist



Time: 114 ms, Memory: 8.00Mb

No tests executed!

Running "qunit:all" (qunit) task
Testing tests/qunit/my-plugin.html 
>> PhantomJS timed out, possibly due to a missing QUnit start() call.
Warning: 1/1 assertions failed (0ms) Use --force to continue.

Aborted due to warnings.

Hello,

Yeoman can't see generator-wp-make after I install it.

Apologies in advance if I'm missing something obvious. I'm new to Yeoman and not sure where to start with debugging it. That said, other generators installed the same way work fine, so it seems to be something specific to this one.

I installed two different ways:

• Cloned the repo locally with the develop branch and used npm link
• Installed from the npm repo with npm install -g generator-wp-make

The result of the following checks is the same with either installation method.

First, I checked I had the latest versions of everything:

ubuntu version 14.04
node version 6.7.0
npm version 3.10.8
yo version 1.8.5
generator-wp-make version 1.0.0

Then, I checked if Yeoman could see it:

$ yo --generators
Available Generators:

  Couldn't find any generators, did you install any? Troubleshoot issues by running

  $ yo doctor

yo doctor reported that everything is fine. I checked my $NODE_PATH to make sure node_modules was there and then checked node_modules to make sure the generator was there.

$ echo $NODE_PATH  
/usr/lib/nodejs:/usr/lib/node_modules:/usr/share/javascript

ls $(npm config get prefix)/lib/node_modules
generator-wp-make  
grunt-cli  
grunt-cssjanus  
grunt-rtlcss  
grunt-sass  
npm  
npm-check-updates  
yo

I tried installing other generators from npm (e.g. npm install -g generator-angular) and those work as expected.

Any suggestions on what I should check next?

Thank you!

We don't always start with WordPress... But that's where we often end up...

Does it make sense to have a way to scaffold a project that's going to start as html, css, and a bit of JS — then have a sub-generator that adds in the WP specific items: functions.php, style.css boilerplate, screenshot.png, pot files, etc?

That way we could start with a minimal project to quickly get in browser, but have a defined scaffold for layering in the WP stuff when it comes time to actually make it into a theme?

Relevant code

function scripts( $debug = false ) {

add_action( 'wp_enqueue_scripts', $n( 'scripts' ) );

wp_enqueue_scripts hook doesn't pass any parameters to the hooked function.

We should remove the $debug = false parameter, unless there is a specific reason why this is present.

Props @ayebare for finding the issue

There may be a discrepancy in what's tagged for release 0.4.0 on npm and what's currently in master (though GitHub is not showing one):

I was trying to get wp-make working today and kept running into issues (npm 3.6.0, yo 1.7.0, wp-make installed via npm install -g generator-wp-make).

List of generators (with blank space below wp-make):

$ yo --help
# ...
Available Generators:

  reveal
    slide
  vvv
    bootstrap
    json
  wp-make

  hubot
    script

Help for the wp-make generator:

$ yo wp-make --help
Usage:
  yo wp-make:app [options]

Options:
  -h,   --help          # Print the generator's options and usage
        --skip-cache    # Do not remember prompt answers             Default: false
        --skip-install  # Do not automatically install dependencies  Default: false

Following the instructions provided in the previous help menu:

$ yo wp-make:app
Invoke a subgenerator to get started!
Available Modules:
    yo wp-make:plugin
    yo wp-make:theme
    yo wp-make:child-theme
    yo wp-make:library

Following the documentation found elsewhere for generating a new theme:

$ yo wp-make:theme
Error wp-make:theme

You don't seem to have a generator with the name wp-make:theme installed.
You can see available generators with npm search yeoman-generator and then install them with npm install [name].
To see the 8 registered generators run yo with the `--help` option.

Once I manually cloned and npm linkd everything, the generator began behaving as expected. Is there a reason why this can't be installed via npm?

The filter is set up to allow a full replacement of the link element which leads to href="' . THEME_TEMPLATE_URL . '/humans.txt" and echo apply_filters( 'theme_humans', $humans ); not being escaped.

FILE: ...tdocs/wp-content/themes/demo-theme/includes/functions/core.php
----------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
----------------------------------------------------------------------
 96 | ERROR | Expected next thing to be an escaping function (see
    |       | Codex for 'Data Validation'), not 'apply_filters'
----------------------------------------------------------------------

Autoprefixer was recently updated to Postcss and the watch task hasn't been updated appropriately. Building fails until the task name is changed.

Had to change tasks/options/watch.js from 'autoprefixer' to 'postcss' per updates to that node module.

Can we have dependencies and devDependencies in the generated package.json so all the tests and stuff aren't run by DeployBot?

While creating a new theme from the generator, I noticed that body classes were not being added to the <body> element. I looked at the theme files being added by the generator and saw that header.php in theme > templates > theme does not include the body class in the <body> element.

I've fixed this in a fix branch and have submitted a pull request. The pull request can be found here -- fix/issue-46.

I tried the wp make plugin sub generator and noticed that the plugin generator didn't import namespace declared in includes core.php into the plugin index

use NameSpace; is missing

Grunt gets pretty slow for things running Sass and minifying JS files. Instead, I think it's worth exploring moving these build steps into Broccoli. Broccoli is made so it works nicely with grunt, but ultimate is smarter about the more build-like steps than grunt is. I haven't done much exploring here, but it's worth a look.

The keys in .jshintrc are not enclosed in quotes.

Currently the core.php calls the i18n function on init. Codex says this should be called within the after_setup_theme action instead.

The generator created namespace classes to get everything started in themes and plugins. However, this is a bit backwards at this point. Instead it should generate namespaces to help push us into the future. These are more easily converted to namespace classes if for some reason we need 5.2 compat.

It should be noted, that each of the items in the namespace classes had a PHP Unit Test written for it as an example. In addition to moving the generated files to namespaces, the example tests need to be migrated and updated as well.

Right now the Readme represents the generator-generator's idea of a basic readme. For this to be useful, the Teadme needs to be fleshed out to provide reference and examples so that it's easier for people to get started, use the product, and contribute back to it.

I followed the steps mentioned in your readme file.

On running yo wp-make am getting:

Error wp-make 

You don't seem to have a generator with the name wp-make installed.
You can see available generators with npm search yeoman-generator and then install them with npm install [name].
To see the 0 registered generators run yo with the `--help` option.

Could you please help?

The license defined isn't in the right form for SPDX licenses, which are used by npm and Composer. It should be "GPL-2.0+" to indicate "GPL version 2 or later".

Currently on the develop branch, yo wp-make:plugin fails to build. This seems to be because of this line, which is looking for a _bowerrc.json starter template (in /src/starters).

Commenting out that line made the generator work fine for me.

I originally pulled in QUnit from Bower, but ultimately, dev dependencies should come from NPM and bower should be left free to manage actual project dependencies. Bower should not be stripped, but shouldn't have Qunit defined in it.

First off, fantastic project. Love it!

Secondly, I realize the readme install instructions suggest cloning with a subsequent npm link, so I'm curious if there is a reason why the npm package is no longer the condoned method for install (e.g. npm install -g generator-wp-make) . The npm package still appears to be published there, https://www.npmjs.com/package/generator-wp-make, however the version listed there is 0.4.3 while the latest release tagged in git is 0.4.2.

Additionally, when I install via npm and try to run yo wp-make:theme, I get the following:

› yo wp-make:theme
Error wp-make:theme

You don't seem to have a generator with the name wp-make:theme installed.
You can see available generators with npm search yeoman-generator and then install them with npm install [name].
To see the 9 registered generators run yo with the `--help` option.

Any ideas? Thanks!

The build task neglects to ignore a few things when generating the zip file. It needs to be audited and refactored to make sure that the resulting zip only contains what is necessary to actually run the final plugin/theme/child theme.

ERROR
>> SyntaxError: Unexpected token }

This is because of this errant bracket:

concat.js code:

module.exports = {
    options: {
        stripBanners: true,
            banner: '/*! <%= pkg.title %> - v<%= pkg.version %>\n' +
        ' * <%= pkg.homepage %>\n' +
        ' * Copyright (c) <%= grunt.template.today("yyyy") %>;' +
            }' * Licensed GPL-2.0+' +
        ' */\n'
    },
    main: {
        src: [
            'assets/js/src/gathercontent-importer.js'
        ],
            dest: 'assets/js/gathercontent-importer.js'
    }
};

uglify.js code:

module.exports = {
    all: {
        files: {
            'assets/js/gathercontent-importer.min.js': ['assets/js/gathercontent-importer.js']
        },
        options: {
            banner: '/*! <%= pkg.title %> - v<%= pkg.version %>\n' +
            ' * <%= pkg.homepage %>\n' +
            ' * Copyright (c) <%= grunt.template.today("yyyy") %>;' +
            }' * Licensed GPL-2.0+' +
            ' */\n',
            mangle: {
                except: ['jQuery']
            }
        }
    }
};

I haven't yet confirmed if other files have the same problem.

I just created a plugin that had a colon in it. It appears when the title contains special characters, these aren't being stripped from the title when it is converted to the namespacing within the code. Creating fatal errors :(

E.G.
Title: 10up: Awesome Plugin
Result in the code: TenUp\10up:_awesome_plugin\Core\setup();

There is an extra test action in generated Gruntfiles that needs to be pulled out. It's not doing anything currently and the behavior is duplicated by a declared grunt task that runs both Qunit and PHPUnit.

Once 10up/Engineering-Best-Practices#143 is merged in to the best practices, it would be a good idea to update the shared/_editorconfig template to match the BP spec.

Right now the generator manually creates the .pot file for the initial setup using a template. The grunt-wp-i18n tools makes it very easy to generate one any time a relevant PHP file is modified.

In discussions with @tlovett1 and @lkwdwrd , we found that we are launching sites with the humans.txt when we shouldn't have. Of course this could be manually avoided, but I think it's worth noting that we might just want to remove this or possibly provide an option to opt-out of the humans.txt for certain sites.

When I try to use wp-make I receive an error saying that "#_ is deprecated. Require your own version of Lodash or underscore.string". I have tried different methods and have been unable to get either Lodash, underscore or wp-make to work.

I tried to use the wp-make generator today after restarting my computer and still get the #_is deprecated error as seen in the screenshot above. The I am running Windows 7 pro 64-bit with these local versions
yo 1.4.7
bower 1.4.1
npm 2.12.0
node 0.12.2
git 1.9.2
wp-make version 0.2.0

Any additional instructions on how to handle this issue would be greatly appreciated.
Any help you can give will be greatly appreciated. Thank you for your time and consideration.

The front end world seems to be talking more and more about libsass. It may be worth embracing this as a means of speeding up builds. There is a node wrapper that might make this an easy transition. There is also a grunt-sass plugin that makes use of libsass, though if we look at broccoli this may not be the direction we want to go.

When first making the generator, it was built off of a WP plugin called CMI-Companion. There are a few places where this still shows up in the resulting generated project. This needs to be stripped out and replaced in the templates to prevent confusion.

This is a nifty generator, I love it

would you consider introducing for :plugin or :theme a .editorconfig file for WordPress standards?

http://editorconfig.org/

possible .editorconfig settings:

https://gist.github.com/nekojira/7ef529df4560c7f4d03d

When I try to use wp-make I receive an error saying that "#_ is deprecated. Require your own version of Lodash or underscore.string". I have tried different methods and have been unable to get either Lodash, underscore or wp-make to work. Any additional instructions on how to handle this issue would be greatly appreciated.Thank you for your time and consideration.

The generator adds a @return statement for every method, even when it's not specifically required.
This is good. 👏

It ends the return type with a full stop (e.g. @return void.), which isn't exactly forbidden by the PHP-FIG proposed standards for docs, but doesn't follow the example.

I propose adjusting the generator to keep the return statements, even if they're not required (yea!), but remove the full stop (boo!).

While themes and plugins are fairly separate, there is a fair bit of code in each of the generators that is the same. It would be very nice to consolidate the various templates into a single file to ease maintenance going forward so that a change made to the Gruntfile in a plugin doesn't also have to be made in the theme and child-theme generators.

I was able to accomplish it in my vvv-generator but never got around to refactoring this generator to make use of shared code.

Currently the version of grunt-contrb-sass doesn't support source maps. The latest version does, you have to do a little dance to get NPM to install the updated version. We need to bump the version numbers of all the npm dependencies to their latest.

When I ran grunt build for the first time on a brand new set of files, I was greeted with this message in copy:main Unable to write "release/0.0.1/assets" file (Error code: EISDIR). Use --force to continue..

Adding expand: true to the copy:main task corrected that.

I'm new to using bower and that so these two questions may seem a bit stupid but here goes:

• I have setup a clean theme and I have installed bower-compass-bootstrap with the -save flag. When I am in the sass file how do I import that? Anything I try isn't working.
• Also how do I get live reload working on this? Is it included? I've just been trying to use grunt without watch just as a test.

I really like your theme generator as a startup. I just need maybe something more of an introduction seeing as i'm not familiar with grunt and that. Can anybody shine some light on this for me please? That would be much appreciated.

With the new version when I run 'yo wp-make:theme' then 'grunt watch' I get an infinite loop with the following error:

Running "watch" task 
Waiting...
Verifying property watch exists in config...ERROR
>> Unable to process task.
Warning: Required config property "watch" missing.

I haven't made any changes to any of the grunt files so I'm not sure why this is happening. Didn't happen with the previous version. Please let me know if this is a bug.

Right now, the JSON configuration files are created through underscores string templating. This seems a bit silly since I've found it's prone to syntax errors if I'm not very careful about how it's being output. We should consider actually building the object in JS, then outputting it into a file with JSON.stringify or similar.

Use a trinary set of setup/load/init functions and hooks.

When generating a new theme, there's little in the way of front-end markup and templating. Once the component library is in a releasable state, what do you think about bringing in some of the basic components (blogroll, author cards, navigation menu, etc)?

If the user skips adding their homepage, the empty string in the composer.json file causes Composer to err on install. If the homepage is not set, we should strip that line from the json file entirely.

Can we update the generated gitignore file with some more standard additions? Suggestion:

/release/
/vendor/
composer.lock
phpunit.xml
.idea

# Sass
.sass-cache
*.map

# NPM
node_modules/

# Editors
*.esproj
*.tmproj
*.tmproject
tmtags
.*.sw[a-z]
*.un~
Session.vim
*.swp

# Mac OSX
.DS_Store
._*
.Spotlight-V100
.Trashes

# Windows
Thumbs.db
Desktop.ini