Originally reported by @MattLewin

Currently, the test case reads:

    public function testOtherWhitespace()
    {
        $this->markTestSkipped();

        $this->assertEquals("Fine. Be that way!", $this->bob->respondTo("\n\r \t\u000b\u00a0\u2002"));
    }

The Unicode characters falling the tab (\t), seem to be incorrectly formatted. They should be \u{000b}\u{00a0}\u{2002}. Otherwise, they are just text and do not count as multi-byte whitespace.

Some exercise README templates contain links to pages which no longer exist in v2 Exercism.

For example, C++'s README template had a link to /languages/cpp for instructions on running tests. The correct URLs to use can be found in the 'Still stuck?' sidebar of exercise pages on the live site. You'll need to join the track and go to the first exercise to see them.

Please update any broken links in the 'config/exercise_readme.go.tmpl' file, and run 'configlet generate .' to generate new exercise READMEs with the fixes.

Instructions for generating READMEs with configlet can be found at:
https://github.com/exercism/docs/blob/master/language-tracks/exercises/anatomy/readmes.md#generating-a-readme

Instructions for installing configlet can be found at:
https://github.com/exercism/docs/blob/bc29a1884da6c401de6f3f211d03aabe53894318/language-tracks/launch/first-exercise.md#the-configlet-tool

Tracking exercism/exercism#4102

Each language track has documentation in the docs/ directory, which gets included on the site
on each track-specific set of pages under /languages.

We've added some general guidelines about how we'd like the track to be documented in exercism/exercism#3315
which can be found at https://github.com/exercism/exercism.io/blob/master/docs/writing-track-documentation.md

Please take a moment to look through the documentation about documentation, and make sure that
the track is following these guidelines. Pay particularly close attention to how to use images
in the markdown files.

Lastly, if you find that the guidelines are confusing or missing important details, then a pull request
would be greatly appreciated.

In exercism/problem-specifications#1501, bracket-push was renamed to matching-brackets in problem-specifications, therefore it is recommended that this track (which has the bracket-push exercise) also renames it.

The reasons for this recommendation:

• to name the exercise by its story, not by what it potentially teaches
• to avoid unnecessarily biasing the solution space

If this track decides to follow this recommendation, here are some things that may need a change:

• config.json
• name of the directory
• README (contains the name of the exercise)
• code

If you're not sure what needs to change, feel free to examine PRs to other tracks by looking at any PRs linked to exercism/problem-specifications#1501.

If this track instead decides that accepting this recommendation is a bad idea for the track, then this issue should be closed upon making that decision, and none of the above steps should be taken.

The unit tests for the exercise are not built correctly according to the README.md specifications. The N is supposed to be a number between 2 - 9 and the unit tests do not test this and furthermore allow for 0 and 1 for the N number.

The link PHP Security Cheatsheet in Useful PHP Resources has been deleted by OWASP. We should remove them.

See https://github.com/exercism/exercism.io/blob/master/.travis.yml#L15

I've configured the web hook, so given a .travis.yml it should trigger the build.

We recently rewrote the test suite for Bowling. Since this track implements Bowling, please take a look at the new canonical_data.json file and see if your track should update its implementation or tests.

The new test suite reorders tests so that students can get to green quickly. It also reduces the number of tests so that students can focus on solving the interesting edge cases.

More details on this change are available in this issue

I made a really stupid choice a while back to commit the cross-compiled
binaries for configlet (the tool that sanity-checks the config.json
against the implemented problems) into the repository itself.

Those binaries are HUGE, and every time they change the entire 4 or 5 megs get
recommitted. This means that cloning the repository takes a ridiculously long
time.

I've added a script that can be run on travis to grab the latest release from
the configlet repository (bin/fetch-configlet), and travis is set up to run
this now instead of using the committed binary.

I would really like to thoroughly delete the binaries from the entire git
history, but this will break all the existing clones and forks.

The commands I would run are:

# ensure this happens on an up-to-date master
git checkout master && git fetch origin && git reset --hard origin/master

# delete from history
git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch bin/configlet-*' --prune-empty

# clean up
rm -rf .git/refs/original/
git reflog expire --all
git gc --aggressive --prune

# push up the new master, force override existing master branch
git push -fu origin master

If we do this everyone who has a fork will need to make sure that their master
is reset to the new upstream master:

git checkout master
git fetch upstream master
git reset --hard upstream/master
git push -fu origin master

We can at-mention (@) all the contributors and everyone who has a fork here in this
issue if we decide to do it.

The important question though, is: Is it worth doing?

Do you have any other suggestions of how to make sure this doesn't confuse people and break their
repository if we do proceed with this change?

We have found that the Isogram tests miss an edge case allowing students to pass all of the current tests with an incorrect implementation.

To cover these cases we have added a new test to the Isogram test set. This new test was added in pull request #265, which also describes the reason for the new test.

Since this track implements Isogram, please take a look at the new isogram.json file and see if your track should update its tests.

If you do need to update your tests, please refer to this issue in your PR. That helps us see which tracks still need to update their tests.

If your track is already up to date, go ahead and close this issue.

More details on this change are available in x-common issue 272.

Thank you for your help!

In order to match the other language directories, the exercises need to be in the root of the project.

Right now moving would break the build, because the tests try to run against ALL the directories in the relevant directory, and it doesn't exclude .git -- so the Makefile will need to be updated.

Some exercises are using the @expectedException annotation, which is deprecated and will be removed in PHPUnit 9:

The @expectedException, @expectedExceptionCode, @expectedExceptionMessage, and @expectedExceptionMessageRegExp annotations are deprecated. 

They will be removed in PHPUnit 9. Refactor your test to use expectException(), expectExceptionCode(), expectExceptionMessage(), or expectExceptionMessageRegExp() instead.

The affected exercises should be updated to use expectExceptionMethod.

(I'm happy to do this myself, when I've got some free time 😄)

The following exercises require updating:

• - largest-series-product
• - phone-number
• - ocr-numbers
• - triangle
• - grains
• - robot-simulator
• - queen-attack

(This is a 'living' list - I'll add exercises as I found them)

See http://help.exercism.io/getting-started-with-go.html as an example.

If appropriate, suggest a linter (see exercism/docs#54).

I've used Sarah Sharp's FOSS Heartbeat project to generate stats for each of the language track repositories, as well as the x-common repository.

The Exercism heartbeat data is published here: https://exercism.github.io/heartbeat/

When looking at the data, please disregard any activity from me (kytrinyx), as I would like to get the language tracks to a point where they are entirely maintained by the community.

Please take a look at the heartbeat data for this track, and answer the following questions:

• To what degree is the track maintained?
• Who (if anyone) is merging pull requests?
• Who (if anyone) is reviewing pull requests?
• Is there someone who is not merging pull requests, but who comments on issues and pull requests, has thoughtful feedback, and is generally helpful? If so, maybe we can invite them to be a maintainer on the track.

I've made up the following scale:

• ORPHANED - Nobody (other than me) has merged anything in the past year.
• ENDANGERED - Somewhere between ORPHANED and AT RISK.
• AT RISK - Two people (other than me) are actively discussing issues and reviewing and merging pull requests.
• MAINTAINED - Three or more people (other than me) are actively discussing issues and reviewing and merging pull requests.

It would also be useful to know if there a lot of activity on the track, or just the occasional issue or comment.

Please report the current status of the track, including your best guess on the above scale, back to the top-level issue in the discussions repository: exercism/discussions#97

TL;DR: the problem specification for the Bob exercise has been updated. Consider updating the test suite for Bob to match.

Details

The problem description for the Bob exercise lists four conditions:

• asking a question
• shouting
• remaining silent
• anything else

There's an ambiguity, however, for shouted questions: should they receive the "asking" response or the "shouting" response?

In exercism/problem-specifications#1025 this ambiguity was resolved by adding an additional rule for shouted questions.

If this track uses exercise generators to update test suites based on the canonical-data.json file from problem-specifications, then now would be a good time to regenerate 'bob'. If not, then it will require a manual update to the test case with input "WHAT THE HELL WERE YOU THINKING?".

See the most recent canonical-data.json file for the exact changes.

Remember to regenerate the exercise README after updating the test suite:

configlet generate . --only=bob --spec-path=<path to your local copy of the problem-specifications repository>

You can download the most recent configlet at https://github.com/exercism/configlet/releases/latest if you don't have it.

Note that pull request #197 locks the problem description for 'bob' to match the current implementation by adding the exercises/bob/.meta/description.md file. If that PR is merged before this issue is resolved, then you will need to delete the exercises/bob/.meta/description.md file as part of the change.

I can't remember the history of this, but we ended up with a weird non-biological thing in the RNA transcription exercise, where some test suites also have tests for transcribing from RNA back to DNA. This makes no sense.

If this track does have tests for the reverse transcription, we should remove them, and also simplify the reference solution to match.

If this track doesn't have any tests for RNA->DNA transcription, then this issue can be closed.

See exercism/problem-specifications#148

As discussed with @wilmoore we should be utilizing the best possible PHP syntax available. When Travis CI supports PHP 5.6 we should update the Example.phps to make use of this.

Although I think we should hold back on using 5.6 features in tests as many users will not update asap.

A duration of a gigasecond should be measured in seconds, not
days.

The gigasecond problem has been implemented in a number of languages,
and this issue has been generated for each of these language tracks.
This may already be fixed in this track, if so, please make a note of it
and close the issue.

There has been some discussion about whether or not gigaseconds should
take daylight savings time into account, and the conclusion was "no", since
not all locations observe daylight savings time.

My solution fails test6 with the following output, after having passed all of the other tests.

Output from the test:

<snip>
There were 2 failures:

1) GigasecondTest::test6
Failed asserting that DateTime Object &000000005023551d000000007ab41f16 (
    'date' => '2046-10-02 01:46:40.000000'
    'timezone_type' => 3
    'timezone' => 'UTC'
) is not equal to DateTime Object &000000005023551d000000007ab41f16 (
    'date' => '2046-10-02 01:46:40.000000'
    'timezone_type' => 3
    'timezone' => 'UTC'
).
</snip>

This is the only test that has a naked date, as opposed to a datetime. I can't tell whether this is expected behavior, and if so, why?

Any help would be appreciated.

Currently we support PHP 7.0 on Travis. There's an open pull request upgrading to 7.1—which was quite painless (we just needed to make a couple of small changes to remove warnings).

In order to upgrade to 7.2 we would need to change the assert() calls to no longer pass string arguments (see http://php.net/manual/en/function.assert.php).

I'm not sure how common it is for people to have older versions of PHP installed locally, and I don't know how easy it is to upgrade if you have an older version (or how easy it is to understand that you need to upgrade), so I am not necessarily recommending that we upgrade to 7.2, just suggesting that we discuss the trade-offs.

In order to launch we should have:

• php as a submodule in x-api
• at least 10 problems
• a "how to get started" topic in the help repo repo (app/pages/languages/getting-started-with-php.md)
• convert wordy to pure function
• convert trinary to pure function
• convert roman-numerals to pure function
• one to a handful of people willing to check exercism regularly (daily?) for nitpicks to ensure that the track gets off on the right foot
• toggle "active" to true in config.json

Some tracks have been more successful than others, and I believe the key features of the successful tracks are:

• each submission receives feedback quickly, preferably within the first 24 hours
• the nitpicks do not direct users to do specific things, but rather ask questions challenging people to think about different aspects of their solution, or explore new aspects of the language.

For more about contributing to language tracks on exercism, check out the Problem API Contributing guide: https://github.com/exercism/x-api/blob/master/CONTRIBUTING.md

Currently some of the tests for exercises use this pattern:

$this->expectException('InvalidArgumentException', 'Only positive numbers are allowed');

This doesn't actually test the exception message; PHPUnit just ignores the second parameter, checking only the exceptions type.

To achieve the desired behaviour, expectExceptionMessage should be used.

In the upcoming release of Configlet v3.8.0, the lint command will now verify that locked exercises meet the unlocked_by criteria, as defined by the track configuration spec:

• Core exercises can not be unlocked by other exercises.
• Non-core exercises can only be unlocked by core exercises.

Before cutting a release of Configlet I am opening issues on all tracks found to contain one or more unlocked_by violations so that maintainers of the track can validate and remedy the violations.

-> The exercise 'collatz-conjecture' is being unlocked by a non-core exercise. Non-core exercises can only be unlocked by core exercises. 
-> The exercise 'crypto-square' is being unlocked by a non-core exercise. Non-core exercises can only be unlocked by core exercises. 
-> The exercise 'series' is being unlocked by a non-core exercise. Non-core exercises can only be unlocked by core exercises. 
-> The exercise 'transpose' is being unlocked by a non-core exercise. Non-core exercises can only be unlocked by core exercises. 
-> The exercise 'meetup' is being unlocked by a non-core exercise. Non-core exercises can only be unlocked by core exercises. 
-> The exercise 'all-your-base' is being unlocked by a non-core exercise. Non-core exercises can only be unlocked by core exercises.

While opening pull requests to reorder Raindrops and Run Length Encoding I noticed that the PHP track doesn't actually have a specified core track, Exercism is just automatically pulling the first eleven exercises from the config.json file. As a result, there are a lot of string manipulation exercises and not a whole lot else until the last two.

To start some discussion on the order I've put together the following track proposal based on the kinds of solutions that I've seen for the existing problems, the concepts introduced by each problem as well as the track ordering for JavaScript, Ruby, Python, Go and Elixir.

1. Hamming
2. Gigasecond
3. Bob
4. RNA Transcription
5. Luhn
6. Isogram
7. Robot Name
8. Difference of Squares
9. Grade School
10. Robot Simulator
11. Run Length Encoding
12. Largest Series Product

Notes

• Removed Pangram as it doesn't usefully introduce anything over the other string manipulation exercises and Isogram is present in most other tracks.
• Removed Raindrops due to it's similarity to Bob and added Luhn as a candidate to replace it.
• Moved Run Length Encoding to the penultimate position, due to the amount of mentoring it can require and propensity to receive spaghetti solutions.
• Moved Difference of Squares earlier in the chain, as it's a simpler exercise.
• Added Robot Name as it introduces randomness and can be used to teach about separation of concerns.
• Added Grade School as it introduces sorting and can be solved with a number of different approaches to the data structure.
• Added Robot Simulator as it introduces multi-dimensional arrays and more complex class structuring.

Further considerations

• I'm not sure about the position of Run Length Encoding. My thinking with placing it in the penultimate position is that it's a lot easier to mentor if the student doesn't need much help with code style and clarity, only the concepts.
• I'm not surre about the position of Difference of Squares, this could possibly come even earlier?
• There are probably a couple of other side exercises that could be moved into the core track to widen the concepts covered.
• The order could be further improved, I'm particularly unsure of where RNA Transcription and Isogram should fit.
• Is Largest Series Product the best final exercise? It would be good to have the final exercise incorporate a number of the concepts introduced earlier, especially focusing on class structure, array and string manipulation. I'm not sure what exercise would be best provide this, however.

What do you think about upgrading all exercises to php 7.1+? Adding types and return types

From issue exercism/exercism#1867

Wikipedia says the Hamming distance is not defined for strings of different length.

I am not saying the problems cannot be different, but for such a well-defined concept it would make sense to stick to one definition, especially when the READMEs provide so little information about what is expected from the implementation.

Let's clean this up so that we're using the official definition.

Per the discussion in exercism/discussions#128 we
will be installing the probot/stale integration on the Exercism organization on
April 10th, 2017.

By default, probot will comment on issues that are older than 60 days, warning
that they are stale. If there is no movement in 7 days, the bot will close the issue.
By default, anything with the labels security or pinned will not be closed by
probot.

If you wish to override these settings, create a .github/stale.yml file as described
in https://github.com/probot/stale#usage, and make sure that it is merged
before April 10th.

If the defaults are fine for this repository, then there is nothing further to do.
You may close this issue.

Is it a hard requirement for php to have camel-cased problem directories?

At the moment all the directories are lowercase and hyphenated, regardless of what the naming convention is for files.

This causes the build to fail, because x-api can't find anything in https://github.com/exercism/x-common that matches Clock or Trinary (it's clock and trinary there).

I made a quick fix that normalises the slug, but then exercism fetch will write it to trinary/TrinaryTest.php rather than Trinary/TrinaryTest.php.

I see two immediate options, but there are probably more.

1. Change the PHP problems so that the containing directories match the x-common metadata slugs.
2. Change x-api so that it can find the metadata based on a normalized version of the name, but use the php-specific names as slugs.

For what it's worth, I have (2) working in a branch, but I don't want to add unnecessary complexity just because I can :-)

Solutions for the anagram exercise would typically take advantage of mb_string function. Some (default) PHP installs won't include this extension, which could lead a user to being unable to complete the exercise if they are unable or unwilling to install the extension.

Can we move the tests that use UTF-8 based characters to being a stretch goal, similar to the Wordy exercise? Otherwise, it might be helpful to put a warning about needing the module.

I was looking at Trinary and the problem seems to be trivialized by the base_convert and intval functions.

I remembered in leap it was explicitly stated that you should not just use the standard library method.

If your language provides a method in the standard library that does this look-up, pretend it doesn't exist and implement it yourself.

How should we handle this problem? Should the README for Trinary be updated with the same requirement?

As we move towards the launch of the new version of Exercism we are going to be ramping up on actively recruiting people to help provide feedback.

Our goal is to get to 100%: everyone who submits a solution and wants feedback should get feedback. Good feedback. You can read more about this aspect of the new site here: http://mentoring.exercism.io/

To do this, we're going to need a lot more information about where we can find language enthusiasts.

• Is PHP supported by one or more large organizations?
• Does PHP have an official community manager?
• Do you know of specific communities (online or offline) that are enthusiastic about PHP? (Chat communities, forums, meetups, student clubs, etc)
• Are there popular conferences for PHP? (If so, what are some examples?)
• Are there any organizations who are targeted specifically at getting certain subgroups or demographics interested in PHP? (e.g. kids, teenagers, career changers, people belonging to various groups that are typically underrepresented in tech?)
• Are there specific groups or programs dedicated to mentoring people in PHP?
• Are there popular newsletters for PHP?
• Is PHP taught at programming bootcamps? (If so, what are some examples?)
• Is PHP taught at universities? (If so, what are some examples?)

In other words: where do people care a lot and/or know a lot about PHP?

This is part of the project being tracked in exercism/meta#103

For the past three years, the ordering of exercises has been done based on gut feelings and wild guesses. As a result, the progression of the exercises has been somewhat haphazard.

In the past few months maintainers of several tracks have invested a great deal of time in analyzing what concepts various exercises require, and then reordering the tracks as a result of that analysis.

It would be useful to bake this data into the track configuration so that we can adjust it over time as we learn more about each exercise.

To this end, we've decided to add a new key exercises in the config.json file, and deprecate the problems key.

See exercism/discussions#60 for details about this decision.

Note that we will not be removing the problems key at this time, as this would break the website and a number of tools.

The process for deprecating the old problems array will be:

• Update all of the track configs to contain the new exercises key, with whatever data we have.
• Simultaneously change the website and tools to support both formats.
• Once all of the tracks have added the exercises key, remove support for the old key in the site and tools.
• Remove the old key from all of the track configs.

In the new format, each exercise is a JSON object with three properties:

• slug: the identifier of the exercise
• difficulty: a number from 1 to 10 where 1 is the easiest and 10 is the most difficult
• topics: an array of strings describing topics relevant to the exercise. We maintain
  a list of common topics at https://github.com/exercism/x-common/blob/master/TOPICS.txt. Do not feel like you need to restrict yourself to this list;
  it's only there so that we don't end up with 20 variations on the same topic. Each
  language is different, and there will likely be topics specific to each language that will
  not make it onto the list.

The difficulty rating can be a very rough estimate.

The topics array can be empty if this analysis has not yet been done.

Example:

"exercises": [
  {
    "slug": "hello-world" ,
    "difficulty": 1,
    "topics": [
        "control-flow (if-statements)",
        "optional values",
        "text formatting"
    ]
  },
  {
    "difficulty": 3,
    "slug": "anagram",
    "topics": [
        "strings",
        "filtering"
    ]
  },
  {
    "difficulty": 10,
    "slug": "forth",
    "topics": [
        "parsing",
        "transforming",
        "stacks"
    ]
  }
]

It may be worth making the change in several passes:

1. Add the exercises key with the array of objects, where difficulty is 1 and topics is empty.
2. Update the difficulty settings to reflect a more accurate guess.
3. Add topics (perhaps one-by-one, in separate pull requests, in order to have useful discussions about each exercise).

Some exercises are using the the optional $delta parameter of assertEquals(), which is and will be removed in PHPUnit 9:

The optional $delta parameter of assertEquals() is deprecated and will be removed in PHPUnit 9. 
Refactor your test to use assertEqualsWithDelta() instead.

The affected exercises should be updated to use assertEqualsWithDelta.

(I'm happy to do this myself, when I've got some free time 😄)

The following exercises require updating:

• - space-age

(This is a 'living' list - I'll add exercises as I found them)

Hi,

We could start using PHPUnit Groups instead of $this->markTestSkipped();

What would this fix

We don't have to remove $this->markTestSkipped(); in order to run all tests.

Example

/**
 * @group ignore
 */
public testSomeFunctionality()
{
}

To run tests that aren't in group ignore:

phpunit --exclude-group=ignore

To run only tests that are in group ignore:

phpunit --group=ignore

Alternative would be adding to phpunit.xml:

<groups>
    <exclude>
        <group>ignore</group>
    </exclude>
</groups>

Which would allow to run just phpunit and only tests that don't have ignore groupe would run by default.

Hi,
the readme of this exercise gives two examples of valid names, both containing two uppercase letters.
the test-suite only checks for two letters.
am i supposed to use only uppercase letters?
in this case the testcase should be changed.
or am i supposed to use lowercase and uppercase letters to increase the uniqe serialnumber-count?
that should be mentioned in the readme.

The problems api (x-api) now supports having exercises collected in a subdirectory
named exercises.

That is to say that instead of having a mix of bin, docs, and individual exercises,
we can have bin, docs, and exercises in the root of the repository, and all
the exercises collected in a subdirectory.

In other words, instead of this:

x{TRACK_ID}/
├── LICENSE
├── README.md
├── bin
│   └── fetch-configlet
├── bowling
│   ├── bowling_test.ext
│   └── example.ext
├── clock
│   ├── clock_test.ext
│   └── example.ext
├── config.json
└── docs
│   ├── ABOUT.md
│   └── img
... etc

we can have something like this:

x{TRACK_ID}/
├── LICENSE
├── README.md
├── bin
│   └── fetch-configlet
├── config.json
├── docs
│   ├── ABOUT.md
│   └── img
├── exercises
│   ├── bowling
│   │   ├── bowling_test.ext
│   │   └── example.ext
│   └── clock
│       ├── clock_test.ext
│       └── example.ext
... etc

This has already been deployed to production, so it's safe to make this change whenever you have time.

@petemcfarlane I can potentially do the Bank Account exercise but looking at the requirements I see that a thread safe implementation is mentioned. Although possible to some extent multithreading in php user land is not common nor encouraged and requires the use of special extension (i.e. pthreads).
I'd argue that you'd never use multithreading for BankAccount implementation in php in real life. All locking would happen at a lower level i.e. database or other type of store (redis)...
So my questions is how essential is the multithreading part is to this exercise and is it worth implementing without it?

Some tracks have added assertions to the exercise test suites that ensure that the solution has a hard-coded version in it.
In the old version of the site, this was useful, as it let commenters see what version of the test suite the code had been written against, and they wouldn't accidentally tell people that their code was wrong, when really the world had just moved on since it was submitted.

If this track does not have any assertions that track versions in the exercise tests, please close this issue.

If this track does have this bookkeeping code, then please remove it from all the exercises.

See exercism/exercism#4266 for the full explanation of this change.

The JSON file containing canonical inputs/outputs for the Clock exercise has gotten new data.

There are two situations that the original data didn't account for:

• Sometimes people perform computation/mutation in the display method instead of in add. This means that you might have two copies of clock that are identical, and if you add 1440 minutes to one and 2880 minutes to the other, they display the same value but are not equal.
• Sometimes people only account for one adjustment in either direction, meaning that if you add 1,000,000 minutes, then the clock would not end up with a valid display time.

If this track has a generator for the Clock exercise, go ahead and regenerate it now. If it doesn't, then please verify the implementation of the test suite against the new data. If any cases are missing, they should be added.

See exercism/problem-specifications#166

There are a number of things we're going to want to check before the v2 site goes live. There are notes below that flesh out all the checklist items.

• The track has a page on the v2 site: https://v2.exercism.io/tracks/php
• The track page has a short description under the name (not starting with TODO)
• The "About" section is a friendly, colloquial, compelling introduction
• The "About" section follows the formatting guidelines
• The code example gives a good taste of the language and fits within the boundaries of the background image
• There are exercises marked as core
• Exercises have rough estimates of difficulty
• Exercises have topics associated with them
• The first exercise is auto_approve: true

Track landing page

The v2 site has a landing page for each track, which should make people want to join it. If the track page is missing, ping @kytrinyx to get it added.

Blurb

If the header of the page starts with TODO, then submit a pull request to https://github.com/exercism/php/blob/master/config.json with a blurb key. Remember to get configlet and run configlet fmt . from the root of the track before submitting.

About section

If the "About" section feels a bit dry, then submit a pull request to https://github.com/exercism/php/blob/master/docs/ABOUT.md with suggested tweaks.

Formatting guidelines

In order to work well with the design of the new site, we're restricting the formatting of the ABOUT.md. It can use:

• Bold
• Italics
• Links
• Bullet lists
• Number lists

Additionally:

• Each sentence should be on its own line
• Paragraphs should be separated by an empty line
• Explicit <br/> can be used to split a paragraph into lines without spacing between them, however this is discouraged.

Code example

If the code example is too short or too wide or too long or too uninteresting, submit a pull request to https://github.com/exercism/ocaml/blob/master/docs/SNIPPET.txt with a suggested replacement.

Exercise metadata

Where the v1 site has a long, linear list of exercises, the v2 site has organized exercises into a small set of required exercises ("core").

If you update the track config, remember to get configlet and run configlet fmt . from the root of the track before submitting.

Topic and difficulty

Core exercises unlock optional additional exercises, which can be filtered by topic an difficulty, however that will only work if we add topics and difficulties to the exercises in the track config, which is in https://github.com/exercism/php/blob/master/config.json

Auto-approval

We've currently made any hello-world exercises auto-approved in the backend of v2. This means that you don't need mentor approval in order to move forward when you've completed that exercise.

Not all tracks have a hello-world, and some tracks might want to auto approve other (or additional) exercises.

Track mentors

There are no bullet points for this one :)

As we move towards the launch of the new version of Exercism we are going to be ramping up on actively recruiting people to help provide feedback. Our goal is to get to 100%: everyone who submits a solution and wants feedback should get feedback. Good feedback.

If you're interested in helping mentor the track, check out http://mentoring.exercism.io/

When all of the boxes are ticked off, please close the issue.

Tracking progress in exercism/meta#104

The old help site was deprecated in December 2015. We now have content that is displayed on the main exercism.io website, under each individual language on http://exercism.io/languages.

The content itself is maintained along with the language track itself, under the docs/ directory.

We decided on this approach since the maintainers of each individual language track are in the best position to review documentation about the language itself or the language track on Exercism.

Please verify that nothing in docs/ refers to the help.exercism.io site. It should instead point to http://exercism.io/languages/:track_id (at the moment the various tabs are not linkable, unfortunately, we may need to reorganize the pages in order to fix that).

Also, some language tracks reference help.exercism.io in the SETUP.md file, which gets included into the README of every single exercise in the track.

We may also have referenced non-track-specific content that lived on help.exercism.io. This content has probably been migrated to the Contributing Guide of the x-common repository. If it has not been migrated, it would be a great help if you opened an issue in x-common so that we can remedy the situation. If possible, please link to the old article in the deprecated help repository.

If nothing in this repository references help.exercism.io, then this can safely be closed.

The function helloWorld is called without passing all required arguments in the tests. This will trigger a warning on 5.6 and later (7.1alpha2 and later throw an exception, currently):

https://3v4l.org/GOT6G

The function signature should be changed to

function helloWorld($name = null)

In cases like #111 where we want to use other PHP classes as fixtures, it'd be nice to include them at the bottom of the test file. This is fairly common in PHP tests. Currently code sniffer will not allow more than one class per file. Excluding PSR1.Classes.ClassDeclaration.MultipleClasses will change this.

We have found that the Pangram tests miss edge cases allowing students to pass all of the current tests with an incorrect implementation.

To cover these cases we have added new tests to the Pangram test set. Those new tests were added in this commit

Since this track implements Pangram, please take a look at the new pangram.json file and see if your track should update its tests.

If you do need to update your tests, please refer to this issue in your PR. That helps us see which tracks still need to update their tests.

If your track is already up to date, go ahead and close this issue.

More details on this change are available in x-common issue 222.

Thank you for your help!

Exercism switched to different naming convention.
xPHP should be change to just PHP

See issue exercism/exercism#2092 for an overview of operation welcome contributors.

Provide instructions on how to contribute patches to the exercism test suites
and examples: dependencies, running the tests, what gets tested on Travis-CI,
etc.

The contributing document
in the x-api repository describes how all the language tracks are put
together, as well as details about the common metadata, and high-level
information about contributing to existing problems, or adding new problems.

The README here should be language-specific, and can point to the contributing
guide for more context.

From the OpenHatch guide:

Here are common elements of setting up a development environment you’ll want your guide to address:

Preparing their computer
Make sure they’re familiar with their operating system’s tools, such as the terminal/command prompt. You can do this by linking to a tutorial and asking contributors to make sure they understand it. There are usually great tutorials already out there - OpenHatch’s command line tutorial can be found here.
If contributors need to set up a virtual environment, access a virtual machine, or download a specific development kit, give them instructions on how to do so.
List any dependencies needed to run your project, and how to install them. If there are good installation guides for those dependencies, link to them.

Downloading the source
Give detailed instructions on how to download the source of the project, including common missteps or obstacles.

How to view/test changes
Give instructions on how to view and test the changes they’ve made. This may vary depending on what they’ve changed, but do your best to cover common changes. This can be as simple as viewing an html document in a browser, but may be more complicated.

Installation will often differ depending on the operating system of the contributor. You will probably need to create separate instructions in various parts of your guide for Windows, Mac and Linux users. If you only want to support development on a single operating system, make sure that is clear to users, ideally in the top-level documentation.

Hi,
As said in the title I face a fatal error when I run bob_test.php.

Error Message:
Fatal error: Declaration of BobTest::setUp() must be compatible with PHPUnit\Framework\TestCase::setUp(): void in C:\laragon\www\Exercism\php\bob\bob_test.php on line 156

PHP version: PHP 7.3.2 (cli) (built: Feb 5 2019 23:14:21)
PHPunit: phpunit-8.0.4.phar
OS: Windows 7

I know a few of the exercises in xpython were updated from classes with a single function to simply functions. I noticed that xphp has a few exercises where I think it'd make sense to use a function rather than a class. Two examples are hamming and leap. They accept one argument on initialization that could be the argument to the function.

No use case is given where the argument needs to be stored with its instance, or the class later being extended. I think it'd be more appropriate to define them as functions.

Does anyone else have an opinion on this?

Right now all of the icons used for the language tracks (which can be seen at http://exercism.io/languages) are stored in the exercism/exercism.io repository in public/img/tracks/. It would make a lot more sense to keep these images along with all of the other language-specific stuff in each individual language track repository.

There's a pull request that is adding support for serving up the track icon from the x-api, which deals with language-specific stuff.

In order to support this change, each track will need to

• create a directory named img/ at the root of this repository if it doesn't already exist, then
• find the correct icon in https://github.com/exercism/exercism.io/tree/master/public/img/tracks, and
• stick it in the img/ directory, and importantly
• name the image icon.png

In other words, at the end of it you should have the following file:

./img/icon.png

See exercism/exercism#2925 for more details.