|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #55197 required validation
Submitted: 2011-07-13 01:14 UTC Modified: 2020-02-02 19:27 UTC
From: Assigned:
Status: Not a bug Package: Online Doc Editor problem
PHP Version: Irrelevant OS: Irrelevant
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
44 - 29 = ?
Subscribe to this entry?

 [2011-07-13 01:14 UTC]

People are creating invalid patches, which are patches that break the build. 
Then, people commit them without first running configure.php

Solution (concept):

Be sure people validate patches before making the commit

Solution (ideas):

Require configure.php to be ran before _any_ commit is made. Either do this 
immediately before commit, OR, allow it to be done while creating the patch and 
track it. Example "Patch FOO (last validated on 1/1/11)" or similar. That gets 
complicated as it requires tracking edits, so doing it before commit may be 


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2011-07-14 05:45 UTC]
Just to add a little weight to this, and specifically for translators, of the 10 
translations, currently 5 have failed to pass configure.php. So no new Windows 
CHMs this week.

Would a "continuous integration" mechanism be suitable.

As I understand things, all of the PhD outputs can be built on Windows, and as 
Windows is required for the CHM and EnhancedCHM builds, it would seem suitable 
to do it all on one machine.

Would constantly building, or at least daily building, with emailed reports for 
failures only (though no news is assumed to be good news - so maybe report every 
build) be a viable solution?

I was thinking something along the lines of but for phpdoc.
 [2011-07-14 05:46 UTC] and shows the 
current log files.
 [2011-07-16 09:34 UTC]
I don't think we need another machine doing that. The machine checks builds for each 
translation and sends emails daily when a build is broken, but there appears to be a bug that is 
preventing or interfering with that now.

However, the intent of this bug report (feature request?) is to prevent the broken build in the first 
 [2017-09-21 15:27 UTC]
> People are creating invalid patches, which are patches that break the build. 
> Then, people commit them without first running configure.php

In my opinion, a failing build is less severe than anybody committing nonsense
(e.g. wrong information, gibberish) which successfully builds. And if a build
fails, it might be sufficient to point the committer to
<>, particularly the section "Validating
your changes".
 [2017-09-21 15:29 UTC]
Ah, well, this is about PhDOE. I'm always running configure after having
committed several patches, and updated my SVN checkout, and I suggest others do
so as well.
 [2020-02-02 19:27 UTC]
-Status: Open +Status: Not a bug
 [2020-02-02 19:27 UTC]
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP --
the problem might already be fixed. Please download a new
PHP version from

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.

Too old ;)


PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Apr 16 07:01:29 2024 UTC