xwp / wp-dev-lib Goto Github PK

When the project includes Codeception tests, the pre-commit and travis.script.sh scripts should run them.

I already have setup pre-commit hook where readme.txt is getting parsed on each commit. Of course if there are any changes.

So when i release my plugin on WordPress.org using svn-push script, it has nothing new to parse in readme.txt and readme.md stays intact as it is.

And then svn-script throws this error and exits.

Please commit (--amend?) the updated readme.md

When I try git status it gives me readne.md in unstaged section. Like below:

I see an if condition here. What could be the significance of it ? Am I missing something here ?

Not sure whether this is an issue or not. But I was facing it and I had to fix it with patch-work.

There's an exclude flag in rsync to fetch repo files from git into svn. Ref.

So what is this doing is; excluding all the assets folder from the repository; and not just the one which is required for banners & screenshots. For example, in my plugin; I'm putting my JS, CSS etc. into app/assets/ folder. Also I've used a few vendor libraries in which assets folder is used. So svn-push script ignores all these folders along with the one with banners; resulting in partial file uploads in WordPress.org SVN repo. And this eventually breaks the plugin functionality.

So what I did to prevent this is; removed the exclude flag for assets from rsync and after that I removed assets folder from svn trunk using rm.

Though this worked for me, I had a hunch that either I'm doing something wrong or missing something in order to use this script.

Suggestions ?

This can set things like:

git config core.fileMode false

Since normally WordPress repos do not include files with execute bit turned on.

This script can then be run by vvv-init.sh.

It would be nice to have a way to format single quote code block from readme.txt into triple quote code block for Github use.

So :
<?php echo 'hello'; ?>

Would appear in readme.md :

<?php echo 'hello'; ?>

https://coveralls.io/

Since Travis CI is testing all branches often times the graphic shows that the build is failing even though the primary/stable branch is passing.

There needs to be an option to only point to the master branch (or whatever the stable branch is) for generating the graphic.

See wp-cli/wp-cli#855 and #15.

I don't think we need to hard-code the previous version to test against. We can just stick with latest and master.

Note also the patch that was made to install-wp-tests.sh

There are cases where one might want the other stuff, but would like to turn of the readme syncing.

I think it would be generally useful to add support in the precommit file for an additional configuration file to be loaded, so that it could be configured/extended without hacking it. I guess that might be for another issue, though.

The VIP pre-commit hook runs JS through YUI Compressor to do syntax checking. We need to do the same for the pre-commit hook and the .travis.yml, something like:

wget https://github.com/yui/yuicompressor/releases/download/v2.4.8/yuicompressor-2.4.8.jar
for js in $(find . -name '*.js'); do
    java -jar yuicompressor-2.4.8.jar -o /dev/null $js 2>&1
    if [ $? != 0 ]; then
        exit 1;
    fi
done

• Check syntax with YUI Compressor
• Check with VIP which other commands are included in the SVN pre-commit hook (see https://github.com/Automattic/vip-quickstart/issues/204)

pdepend can generate a large set of software metrics from a given code base. These values can be used to measure the quality of a software project and they help to identify the parts of an application where a code refactoring should be applied.
http://phpqatools.org/

http://pdepend.org/

In the course of time, those who have the most impact on a plugin's development changes, and they should be properly recognized for their contributions. One way to do so is to have them appear higher in the list of contributors on the WordPress.org plugin page. The initial developer(s) of the plugin should probably remain at the top of the contributors list.

To accomplish the above, a file will need to be added to each project which maps WordPress.org usernames to the author names used in the Git commits.

See #44

When there's no files to be deleted according this logic svn rm commands fails in syntax as it does not get any files to remove as expected.

An empty string check needs to be added.

From contributing.md:

Pull requests should be opened with the develop branch as the base. Do not open pull requests into the master branch, as this branch contains the latest stable release.

But there isn't any develop branch at the moment.

AFAIK the only way to achieve a code block in readme.txt is to use the <pre> tag.

It would be nice to add support for a lang attribute so that syntax highlighting can be added when converting to markdown.

TXT

<pre lang="php">
function foo() {
    $bar = 'baz';
}
</pre>

Markdown

function foo() {
    $bar = 'baz';
}

In .travis.yml and pre-commit, it is referenced as ruleset.xml. However, the name of the file in the repo, and the symlink created by following the readme's instructions, is phpcs.ruleset.xml. This may be intended, but I don't see any documentation to that effect. (My 2¢: I'd prefer to just make it phpcs.ruleset.xml across the board, if there is no intended difference.)

phpmd scans PHP source code and looks for potential problems such as possible bugs, dead code, suboptimal code, and overcomplicated expressions.
http://phpqatools.org/

http://phpmd.org/

https://github.com/sebastianbergmann/phpcpd

https://github.com/michael-cannon/custom-bulkquick-edit/blob/006c868161610c02edcb695b675a781018ecdd9f/.travis.yml#L22

I recently pushed a brand new project to WP.org and the assets dir did not transfer to the SVN repo.

My steps were simply adding a svn-url file and running $ dev-lib/svn-push.

Same reasons as #21

Plugins and themes should be able to easily tap into using QUnit to test JS.

I'm currently using:

xmllint --noout $(find . ! -path "./dev-lib/*" ! -path "./vendor/*" \( -name '*.xml' -o -name '*.xml.dist' \))

Other things will usually break anyway if these are invalid, though.

May be part of PHP_CodeSniffer.

Travis check for errors added to log for standard http requests or during unit test running. We could do this by temporarily changing the location of the error_log and then after running all of the unit tests, check to see if error|warning|notice or any of the other strings appear in the log. If they do not appear, or if the log is empty, the test passes.

• Check if a text-domain header exists ( if is a plugin / theme )
• Check all instances of translation functions to confirm the text domain is typed correctly

Consolidate default environment variables into a common script included by both Travis and pre-commit hook. Reduce redundancy.

For instance:

*.sh text eol=lf
*.php text eol=lf
*.js text eol=lf
*.css text eol=lf
*.less text eol=lf
*.scss text eol=lf

*.sql merge=binary

As per Travis documentation, I think it's best to show the readme build status on the master branch only.

Need to add it here: https://github.com/x-team/wp-plugin-dev-lib/blob/5de1b8e9338ddce03e4ebdfe3f3cc77794c8686b/class-wordpress-readme-parser.php#L88-L93

See: http://make.wordpress.org/core/2010/02/20/plugins-can-now-include-videos-in-their-readme-txt-files/

Transform the following in readme.txt:

[youtube http://www.youtube.com/watch?v=D1GHc5OGWEQ]

Into the following in readme.md:

[![Play video on YouTube](http://i1.ytimg.com/vi/D1GHc5OGWEQ/hqdefault.jpg)](http://www.youtube.com/watch?v=D1GHc5OGWEQ)

Today I did a force push on a repo to update some assets and the script hung.

How do I unlock and destroy the temp directory so I can try the push again?

Currently, a fix can be applied but not staged, and this passes JSHint. We need to pass the staged file into JSHint instead.

Something like https://www.npmjs.org/package/grunt-w3c-validation would be a great thing to have.

https://github.com/padraic/mockery

https://github.com/mdevils/node-jscs

Work out ruleset for WordPress JS.

There should be a .ci-config.sh (or something) which exports various Bash variables which can be read-in by .travis.yml and bin/pre-commit.These variables can control things like:

• Allow readme syncing to be disabled (#28)
• Where to fetch PHP_CodeSniffer from (also should grab from GitHub instead of Pear), and which branch or tag to use.
• Where to fetch WordPress Coding Standards from, and which branch/tag/commit to use.
• Path to phpunit.xml
• Path to PHPCS ruleset XML file.
• URL for Travis build button (for generate-markdown-readme), instead of pulling from the git remote

Others?

The tests are being run using WordPress's old unit testing framework, which is no longer maintained: http://unit-tests.svn.wordpress.org/trunk/ (https://unit-tests.trac.wordpress.org/)

I don't know if there are many very significant improvements in the maintained framework, but there have been a few bugfixes. So I think we should move toward using the current framework for the tests.