PHP Wiki - ideas

automaticcodechecker

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/10/19 23:15		current
Line 2:		Line 2:
	//Possible mentor: [[nlopess@php.net\|Nuno Lopes]]//		//Possible mentor: [[nlopess@php.net\|Nuno Lopes]]//

-	The PHP API has a couple of functions that are error prone and may easily cause segfaults in PHP, especially on less used platforms. The list of such functions include zend_parse_parameters(), zend_error() and a few others. Our current check script is made in PHP and is regex based. It is available in [[http://cvs.php.net/viewvc.cgi/php-src/scripts/dev/check_parameters.php?view=markup\|CVS*]]. This script is difficult to maintain and generates way too many false-positives. The work would involve creating a [[http://clang.llvm.org/StaticAnalysis.html\|LLVM clang]] analysis tool to perform some data-flow static analysis and output error messages for the problems found. A sample output of the script mentioned is available at: [[http://gcov.php.net/viewer.php?version=PHP_HEAD&func=params\|http://gcov.php.net]].	+	The PHP API has a couple of functions that are error prone and may easily cause segfaults in PHP, especially on less used platforms. The list of such functions include zend_parse_parameters(), zend_error() and a few others. Our current check script is made in PHP and is regex based. It is available in [[http://svn.php.net/viewvc/web/php-gcov/trunk/cron/check_parameters.php?view=markup\|SVN*]]. This script is difficult to maintain and generates way too many false-positives. The work would involve creating a [[http://clang.llvm.org/StaticAnalysis.html\|LLVM clang]] analysis tool to perform some data-flow static analysis and output error messages for the problems found. A sample output of the script mentioned is available at: [[http://gcov.php.net/viewer.php?version=PHP_HEAD&func=params\|http://gcov.php.net]].

	==== Progress ====		==== Progress ====

bugsupdate

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2010/02/28 22:59		current
Line 1:		Line 1:
	===== Bugs update =====		===== Bugs update =====
-	//Possible mentor: [[kalle@php.net\|Kalle Sommer Nielsen]]//	+	//Person implementing: [[philip@php.net\|Philip Olson]]//

	Currently, internals@ receives weekly emails that list all the [internal] open PHP bugs. Although separated by major PHP version (5 and 6), this information is overwhelming and probably is not very useful. This task involves making it useful. Ideas include tracking closed/open bugs and seemingly unmaintained extensions.		Currently, internals@ receives weekly emails that list all the [internal] open PHP bugs. Although separated by major PHP version (5 and 6), this information is overwhelming and probably is not very useful. This task involves making it useful. Ideas include tracking closed/open bugs and seemingly unmaintained extensions.
Line 8:		Line 8:
	==== Progress ====		==== Progress ====
	* Brief discussion: [[http://markmail.org/thread/q3ufffj4iubl225y#query:+page:1+mid:fm6bmwtp5kkvkt7l+state:results\|Jan 25, 2010 discussion]]		* Brief discussion: [[http://markmail.org/thread/q3ufffj4iubl225y#query:+page:1+mid:fm6bmwtp5kkvkt7l+state:results\|Jan 25, 2010 discussion]]
		+	* Related [[http://bugs.php.net/bug.php?id=51481\|open bug report]]

	==== Status ====		==== Status ====
-	Open	+	In progress

bugtracker

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/01/18 09:17		current
Line 44:		Line 44:

	==== Clearly specify responsibilities ====		==== Clearly specify responsibilities ====
-	Currently it's not clear who's "in charge" of the bugtracker. It would be great to have "a face to the customer" that people can address when somethings unclear. It can also improve the internal workflows when someone takes the responsibility to check that everything works as it is supposed to. So to say a "Project Lead" for the bugs.project.php-project	+	Currently it's not clear who's "in charge" of the bugtracker. It would be great to have "a face to the customer" that people can address when somethings unclear. It can also improve the internal workflows when someone takes the responsibility to check that everything works as it is supposed to. So to say a "Project Lead" for the bugs.project.php-project\\
	~~heiglandreas		~~heiglandreas

Line 55:		Line 55:
	Maybe we should consider external search engine like Shpinx/Solr/Elasticsearch etc?\\		Maybe we should consider external search engine like Shpinx/Solr/Elasticsearch etc?\\
	~~sobak		~~sobak
		+
		+	That would be awesome as it would help with fulltext search which is currently not really working well. Whether that means moving the bugtracker backend to an external searchengine instead of getting rid of the MDB2 or optimizing the fulltext search within MySQL isa different story IMHO\\
		+	~~heiglandreas

	==== Better UX for not-logged in people ====		==== Better UX for not-logged in people ====

buildbot

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2009/08/27 10:40		current
Line 23:		Line 23:
	==== Coverage and Grind build ====		==== Coverage and Grind build ====
	* Generate Valgrind Reports and report overall failed tests		* Generate Valgrind Reports and report overall failed tests
-	* Maybe run n special boxes ?	+	* Maybe run n special boxes ?
		+
		+	==== Extension level build with coverage ====
		+	* PHP Core and One Extension is tested
		+	* With Coverage
		+	* Triggered once a day
		+
		+	==== Extension Level Builds without coverage ====
		+	* Triggered on checkin on this extension

	==== Progress ====		==== Progress ====

bytecodetollvm

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2010/01/08 21:11		current
Line 7:		Line 7:
	==== Status ====		==== Status ====
	Code that does basic JITing works. It can run successfully most of the test suite already.		Code that does basic JITing works. It can run successfully most of the test suite already.
		+	Needs heavy refactoring for newer LLVM versions.

dependencyinterfaceapi

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/05/13 07:18	current
Line 1:	Line 1:
	+	===== Abstract Extension API and Dependency Interface =====
	+	//Possible mentors: [[shire@php.net\|Brian Shire]], [[andrei@php.net\|Andrei Zmievski]]//

	+	==== Description ====
	+	Currently, PHP extensions that have dependencies on other extensions use compile-time configure checks to verify availability. This has several problems:
	+	* Any dependency that is not available will trigger undefined symbol errors, likely at run-time, see: [[http://marc.info/?l=php-internals&m=123456185115526&w=2]].
	+	* Load order is important, as loading the dependency after the dependent extension also triggers symbol errors.
	+	* Upgrading an extension can easily break binary compatibility creating undefined behavior.
	+	* The errors given to the end-user are not always obvious or easy for them to debug.
	+	* On systems where symbols are resolved lazily, the error will not manifest until the code path is executed. This makes debugging difficult, and unexpected.
	+
	+	==== Deliverables ====
	+	* Develop functionality for PHP that will allow extensions to register a set of functions as a versioned API.
	+	* Other extensions should be able to fetch this API, or handle failures appropriately for their application such as disabling features or generating an error. This includes dependencies being unavailable, or not having the expected version. The calling extension should be able to differentiate between these conditions.
	+	* The interface should support extensions being loaded in any order.
	+	* Extensions should be able to support multiple API versions at the same time for backwards compatibility.
	+
	+	==== Initial Brainstorming and Design ====
	+	* The API functions will be passed via a extension specific structure containing function pointers. This requires that extenions share a common prototype for via a C header file. Getting the correct prototype for the correct API version will of course be critical.
	+	* During module initialization the extension will provide a set of API structures that it supports that contain the function pointers. This can be called multiple times with different version numbers.
	+	* The extension can also request an API structure for a specific extension and API version at module initialization. The problem of extension load order needs to be solved here, as returning the API structure will likely need to be delayed until after module initialization but not before request initialization to avoid incurring this cost on every request.
	+	* It may be useful if this interface can be used by PHP to expose callback hooks or interfaces to extensions that may change in the future or need to be abstracted for extension use.
	+	* Having the ability to list dependencies of extensions, and exposed API's could be useful for informational purposes and documentation.
	+
	+	<code C>
	+	/* expose API to other extensions
	+	* we'll be exposing a fetch() function and a store() function
	+	* from our extension. This could be any calls we want to expose.
	+	* extension_api_t is a custom structure for this extension with
	+	* function pointers defining this extension's API.
	+	*/
	+	struct extension_api_t api;
	+	api.version = 1;
	+	api.fetch = my_fetch;
	+	api.store = my_store;
	+	php_register_api(&api)
	+	</code>
	+
	+	<code C>
	+	/* fetch external extension API */
	+	int rval;
	+	int version = 2;
	+	struct extension_api_t *api;
	+
	+	rval = php_get_api('myextension', version, &api);
	+
	+	if (rval == PHP_EXT_UNAVAIL) {
	+	zend_error(E_WARNING, "myextension is not loaded or available, disabling feature");
	+	return NULL;
	+	} else if (rval == PHP_EXT_NOVERSION) {
	+	zend_error(E_WARNING, "myextension version %d is required, disabling feature", version);
	+	return NULL;
	+	} else {
	+	return api->fetch(key);
	+	}
	+	</code>
	+
	+	==== Status ====
	+	Unknown.
	+
	+	==== Progress ====
	+	Unknown.

doodle_closeon_test

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2022/10/07 09:38		current
Line 1:		Line 1:
	~~NOCACHE~~		~~NOCACHE~~

-	<doodle title="Test Doodle for closeon" auth="timwolla" voteType="single" closed="false" closeon="2022-10-07T09:39:00Z">	+	<doodle title="Test Doodle for closeon" auth="timwolla" voteType="single" closed="false" closeon="2022-10-07T09:41:00Z">
	* Yes		* Yes
	* No		* No

fastcgiwork

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/05/13 07:18	current
Line 1:	Line 1:
	+	===== CGI/FastCGI SAPI Improvement =====
	+	//Possible mentors: [[dmitry@zend.com\|Dmitry Stogov]] //

	+	php-cgi is not useful in production environment without additional "crutches" (e.g. spawn-fcgi from [[http://www.lighttpd.net/\|lighttpd]] distribution or [[http://php-fpm.anight.org/\|php-fpm patch]]).
	+	This project assumes integration of such "crutches" and extending php-cgi to support for different protocols.
	+
	+	* daemonization (detach, pid file creation, setup environment variables, setuid/setgid/chroot)
	+	* graceful restart
	+	* separate and improve transport layer to allow support for different protocols
	+	* support for [[http://python.ca/scgi/protocol.txt\|SCGI]] protocol
	+	* support for subset of HTTP protocol
	+	* ...
	+
	+	==== Progress ====
	+	Unknown
	+
	+	==== Status ====
	+	Unknown

getinvolved

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2010/02/24 04:41		current
Line 18:		Line 18:
	* [[doc/scratchpad/wheretohelp\|Where to Help]] - A scratchpad with ideas for explaining where/how to help		* [[doc/scratchpad/wheretohelp\|Where to Help]] - A scratchpad with ideas for explaining where/how to help
	* [[doc/howto\|A DOC HOWTO guide]] - A guide for getting involved with documentation		* [[doc/howto\|A DOC HOWTO guide]] - A guide for getting involved with documentation
		+	* [[http://www.phparch.com/files/2010/07/PHPA-JUL-10-community.pdf]] - Hannes wrote a PHP\|Arch article that may be helpful
	==== Status ====		==== Status ====
	Started, but in need of volunteers (including new people to ask questions).		Started, but in need of volunteers (including new people to ask questions).

gtkcodecomplete

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/05/13 07:18	current
Line 1:	Line 1:
	+	===== PHP-GTK Code Completion =====
	+	//Possible mentors: [[emsmith@php.net\|Elizabeth M Smith]] //

	+	PHP-GTK does not implement all functions for the latest versions of GTK+. This project primarily involves writing overrides for functions whose implementation is not automatically created by the generator. At the end of the project, all functions defined up to the latest version of GTK+ will be expected to work. This will include not only the GTK symbols but the latest version of ATK, Pango, and Gdk.
	+
	+	==== Progress ====
	+	Unknown
	+
	+	==== Status ====
	+	Unknown

integratedcodecoverage

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/05/13 07:18	current
Line 1:	Line 1:
	+	===== Integrated Code Coverage of C and PHP Code =====
	+	//Possible mentor: [[sebastian@php.net\|Sebastian Bergmann]]//

	+	Implement a parser for gcov data files ([[http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Gcov-Data-Files.html#Gcov-Data-Files\|#1]], [[http://gcc.gnu.org/viewcvs/branches/gcc-4_3-branch/gcc/gcov-io.h?view=markup\|#2]]) in PHP. This would be helpful for developers that write both C-level and PHP-level code for their PHP applications and are interested in an integrated code coverage report.
	+
	+	==== Progress ====
	+	None.
	+
	+	==== Status ====
	+	Ideas stage, open.

language-feature-usage-survey

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/05/13 07:18	current
Line 1:	Line 1:
	+	===== Language Feature Usage Survey =====
	+	//Lead: [[bishop@php.net\|Bishop Bettini]]//,
	+	//Working Group Members: TBD//

	+	The engine development team ("internals", [[mailto:internals@lists.php.net\|internals@lists.php.net]]) continually evolves the PHP language, doing so with a healthy respect for preserving backwards compatibility (BC). When the need - or option - for compatibility breaks arise, internals asks the question: "is the risk of breaking this behavior for existing code worth the gain of doing so?"
	+
	+	It's a tough - and subjective - question to answer. Given the sheer volume of PHP installations, it's impossible to speculate how many sites would be affected by a BC break. So without robust information otherwise, the internals team rushes into the debate using a variety of appeals:
	+
	+	* The appeal to statistics. The reasoning goes like this: "The feature has been around a long time, and there are millions of sites, so it's likely that a high percentage of those sites would be affected."
	+	* The appeal to personal experience. This reads like: "I have never used this feature. I've asked all my colleagues: they've never used this feature. I've been doing this for decades, and I've seen it all, so this feature must not be used at all."
	+	* The appeal to [[https://packagist.org/\|Packagist]]. "I scanned the N most popular open-source packages and counted how many times the feature's used. It was used X times, and 80% of those were in tests, so it's not used much in production code."
	+
	+	Those involved in the debate pick a statistic that resonates, then argue using that statistic as if it was a fact. They're not facts, unfortunately. They're cherry-picked statistics, and no way to make a crucial decision.
	+
	+	==== Idea ====
	+
	+	Let's ask users to send us information about how they're using PHP. Let's build an official static analyzer, which writes its results into a published interchange format, and offers to securely send analysis results to an official repository. Let's work with existing static analyzers and code editors to integrate this into their products. Let's work with continuous integration companies to get the tool as part of their pipeline offerings. Let's promote it on Reddit, Packagist, Github, StackOverflow, and any and everywhere else a developer visits.
	+
	+	=== Benefits ===
	+
	+	To PHP users:
	+	* Representation. When they participate, they know internals will consider their specific usage in evolving design.
	+	* Early warning. If internals made a breaking change, be it big or small, the analyzer will flag it.
	+	* Quality guidance. If internals has deprecated a feature, or has detected a usage that may be vulnerable, the analyzer will flag it.
	+
	+	To PHP internals:
	+	* Data, data, data. With real-world metrics at our finger-tips, we can make informed decisions.
	+	* Encourage change. If a feature has little real-world usage, we have the option to proactively remove it.
	+	* Discourage disruption. If a feature has substantial real-world usage, RFC authors can save their time and work on something that can be changed.
	+
	+	To existing static analysis tools:
	+	* Offload work. Fewer rules to maintain, as they can be handled upstream.
	+	* An open interchange format.
	+
	+	To code editors and continuous integration service vendors:
	+	* Distinguish themselves from the competition.
	+	* Help their customers produce better code, meaning more opportunity to gather new customers.
	+
	+	=== Requirements ===
	+
	+	The tool must be:
	+	* Capable of running correctly on PHP 5.0+
	+	* Quick to run / Efficient in time (measured in RPS, rules per second)
	+	* Small footprint / Efficient in space (measured in bytes)
	+	* Available as a standalone program, from an out-of-band download
	+	* Available to download, in-band, from the php cli executable
	+	* Analysis results:
	+	* Sending results to official PHP repository is _optional_
	+	* Transmission is secure only, and obviously so
	+	* Anonymous by default
	+	* Resistant to spamming
	+	* Timestamped
	+
	+	==== Progress ====
	+	Idea definition only.
	+
	+	==== Status ====
	+	Idea only.

patchserver

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/05/13 07:18	current
Line 1:	Line 1:
	+	===== Patch Server =====
	+	//Possible mentor: [[unknown@php.net\|Unknown]]//

	+	This is a system that hosts patches for the PHP project. An example usage is someone posts a patch to a mailing list, and instead of using a random server or pastebin they use this system at php.net to store and archive the patches. Likely related features would be added to enhance the archival and author experience. Experimental patches could also be stored here, although SVN is another option for that (perhaps both, as svn.php.net would probably be the storage backend for this patch server).
	+
	+	In related news, once upon a time Zend hosted a "[[http://devzone.zend.com/article/1432\|PAT Directory]]" so patches wouldn't be forgotten.
	+
	+	==== Progress ====
	+	None
	+
	+	==== Status ====
	+	Open

php6

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/04/02 11:25		current
Line 26:		Line 26:
	* bundle pecl's http (add http2 support too)		* bundle pecl's http (add http2 support too)

-	===== OpCache integraton =====	+	===== OpCache integration =====

	Opcache has been bundled with 5.5.0. A real integration did not happen yet while stabilizing it was the highest priority.		Opcache has been bundled with 5.5.0. A real integration did not happen yet while stabilizing it was the highest priority.
Line 97:		Line 97:
	===== Improve OPcodes, compilation and runtime =====		===== Improve OPcodes, compilation and runtime =====

-	PHP mainly got new opcodes, growing in almost all major versions but never actually git a redesign/rewamp. Old design choices (due to technically limitation or performance reasons f.e.) have been kept in there for ages.	+	PHP mainly got new opcodes, growing in almost all major versions but never actually did a redesign/revamp. Old design choices (due to technically limitation or performance reasons f.e.) have been kept in there for ages.

	Some of these choices cause us troubles with the recent additions (OpCache), like the absolute address usage for jump/call operations.		Some of these choices cause us troubles with the recent additions (OpCache), like the absolute address usage for jump/call operations.

phplogin

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 15:		Line 15:
	==== Progress ====		==== Progress ====

-	Writing the first draft of this wiki page...	+	[[mailto:aaronjunker@php.net\|]] is making a RFC that proposes a global login system.

	==== Status ====		==== Status ====

phpnetauth

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2010/01/08 21:11		current
Line 20:		Line 20:
	* Consider binding VCS access control on a per-user basis (eliminating the avail file)		* Consider binding VCS access control on a per-user basis (eliminating the avail file)
	* RIP Magical Cookie, and thanks for all the memories		* RIP Magical Cookie, and thanks for all the memories
		+	* Consider a fallback system for those who prefer separate logins to each site. This suggests a new auth backend that OpenID can be plugged into.

	==== Status ====		==== Status ====

phpnetmirroring

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/05/13 07:18	current
Line 1:	Line 1:
	+	===== New Mirror Management System =====
	+	// Possible Mentor: [[danbrown@php.net\|Daniel P. Brown]] //

	+	==== Description ====
	+	Our existing management system for the network of official mirrors worldwide has a few issues and areas for improvement. The present system is accessible via a browser-based web interface (using a php.net CVS account, and hosted on master.php.net), and provides the following services:
	+
	+	* Addition, deletion, and modification of DNS for official mirrors of the php.net site as a whole
	+	* Automated checking of all mirrors, marking mirrors as "disabled" when issues are detected
	+	* Listing of all mirrors presently configured with the system (active and otherwise)
	+	* Manual disabling of mirrors
	+	* Generic status display of the "health" of the mirror ("OK" or flagged)
	+	* Ability to edit the mirror's display information within our list on php.net
	+	* Automated mailing to the mirror's maintainer when an issue is detected
	+	* Automated mailing of the status of all mirrors on a weekly basis
	+
	+	Over time, some of the php.net mirror admins have discussed the need and/or desire to add new - or improve existing - functionality in this system. This includes, but is not limited to:
	+
	+	* Improved mirror status checking
	+	* The ability to keep logs of notes regarding the mirror over time, displaying the most recent on the summary page
	+	* Simple graphing and statistics for uptime and PING response time
	+	* A geo-IP lookup to ensure that the mirror IP address matches the physical region it serves
	+	* An online "waiting list" application form (many potential donors currently contact the mailing list or Dan Brown directly)
	+	* An online form to collect data from mirror maintainer applicants
	+	* A form-to-mail interface to email individual maintainers, the mailing list, or all maintainers directly (for announcements)
	+	* Number of interested donors on the "waiting list" under each country's heading
	+	* Automated quarterly reminders to folks on the "waiting list" to update their status if they are no longer willing/able (?)
	+	* System specifications on each individual mirror (?)
	+	* A scoring system based on the system specs of the mirrors (?)
	+	* Load-balancing based upon the score of the mirror when redirecting to a local mirror in the region (?)
	+	* Automated daily reminder emails to mirror maintainer when mirror is out-of-sync > 24 hours (still auto-disabled) (?)
	+	* .... etc.
	+
	+	==== Progress ====
	+	A few points integrated.
	+
	+	==== Status ====
	+	Open.
	+
	+	==== TODO ====
	+	* Document currently used process and tools
	+	* Also note that several related bugs exist

phpnetsearch

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/07/16 04:23		current
Line 26:		Line 26:
	* Integrate errors.inc magic into the search		* Integrate errors.inc magic into the search
	* Track when we choose the page for them (ex: search for strlen goes to its functions page) and offer a "Did you mean foo() or bar()?" snippet		* Track when we choose the page for them (ex: search for strlen goes to its functions page) and offer a "Did you mean foo() or bar()?" snippet
-	* Write an sqlite wrapper so we won't require ref.sqlite (thus allowing more mirrors to utilize the sqlite based search) See: [[ideas:phpnetsearchsqlite]]	+	* <del>Move from ext/sqlite to pdo_sqlite. See: [[ideas:phpnetsearchsqlite]]</del> (done -Philip)
		+	* <del>Add search snippets for commonly searched terms</del> (proof-of-concept ([[http://php.net/str\|Ex]]) implemented -Philip)
	* <del>Take into account language when doing a search (do not show fr/ results when language en/ is chosen)</del> (done -Rasmus)		* <del>Take into account language when doing a search (do not show fr/ results when language en/ is chosen)</del> (done -Rasmus)
	* Consider alternative my.php options including preferred default search method		* Consider alternative my.php options including preferred default search method
Line 34:		Line 35:
	* On May 5, 2009 the default search type changed from 'function list' to 'online documentation' but after feedback was changed back within 3 days		* On May 5, 2009 the default search type changed from 'function list' to 'online documentation' but after feedback was changed back within 3 days
	* This topic should also be discussed while the site is redesigned (20xx)		* This topic should also be discussed while the site is redesigned (20xx)
-	* About 102/109 of mirrors have pdo_sqlite but not ext/sqlite (we only use ext/sqlite currently)	+	* About 102/109 of mirrors have pdo_sqlite <del>but not ext/sqlite (we only use ext/sqlite currently)</del>

phpnetsearchsqlite

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/05/13 07:18	current
Line 1:	Line 1:
	+	===== PHP.net search SQLite wrapper =====
	+	//Possible mentors: [[unknown@php.net\|Unknown]] //

	+	This is a side project of the [[ideas:phpnetsearch]] idea, but is specific to our SQLite search at php.net. Each mirror has one of four SQLite extensions installed, so this wrapper will allow the SQLite part of our search to work on all mirrors. It'll utilize the specific features we utilize today, yet also allow flexibility for future enhancements and features.
	+
	+	The SQLite extensions that should work: ext/sqlite ext/sqlite3 pdo::sqlite pdo::sqlite2
	+
	+	Other work includes improving the sqlite database(s) that we use for search.
	+
	+	==== Progress ====
	+	None
	+
	+	==== Status ====
	+	Ideas stage

runtests

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/05/13 07:18	current
Line 1:	Line 1:
	+	===== run-tests.php improvements =====
	+	//Possible mentors: [[zoe@php.net\|Zoe Slattery]] [[stefan.priebsch@e-novative.de\|Stefan Priebsch]]//

	+	The current version of run-tests.php is a PHP 4 scripts which has grown over the years. We currently have about 8000 tests in PHP and running them sequentially using the existing script is beginning to take an unacceptably long time, the problem will only get worse as we add more tests. We prototyped parallel test execution a while ago and found that it could be done but it was impossibly difficult to do using the existing run-tests.php script. There are other improvements that we'd like to add to run-tests (for example XML output) which we thought would also be easier if the existing run-tests.php script was re-engineered. Over the past few months we have been working on this and have a prototype OO version of run-tests that is currently able to run most of the tests in ex/standard/tests. The code is designed so that adding parallel running will be easy, we'd like to propose that a student takes on (at least) this part of the work - it's interesting and quite difficult PHP coding. A good student could extend beyond this and implement other new features (XML, reporting).
	+
	+	==== Progress ====
	+	* Initial work by Zoe (where?)
	+	* [[:GSoC:2009:runtests\|GSoC 2009]]
	+
	+	==== Status ====
	+	Actively being worked on.

template

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/05/13 07:18	current
Line 1:	Line 1:
	+	===== The idea title =====
	+	//Possible mentor: [[unknown@php.net\|unknown]]//
	+
	+	Description of the idea
	+
	+	==== Progress ====
	+	List the progress that has been made, and/or links to discussions (usually on the php.net mailing lists) that relate.
	+
	+	==== Status ====
	+	The current status.

usercomments

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2012/09/09 08:37		current
Line 93:		Line 93:
	* The existing user notes were always sorted by date of submission in descending order. This made the usefulness of older notes degrade slowly over time as more and more notes for the same page were added and notes of a lesser quality were not removed.		* The existing user notes were always sorted by date of submission in descending order. This made the usefulness of older notes degrade slowly over time as more and more notes for the same page were added and notes of a lesser quality were not removed.
	* The new features allows the notes to be sorted by a rating system of +/- 1 based on number of votes and grouped by dates in a descending order. The rating is calculated by dividing the number of +1 (up votes) by the number of total votes (up votes plus down votes) -- calculated as a percentage of 0 - 100%.		* The new features allows the notes to be sorted by a rating system of +/- 1 based on number of votes and grouped by dates in a descending order. The rating is calculated by dividing the number of +1 (up votes) by the number of total votes (up votes plus down votes) -- calculated as a percentage of 0 - 100%.
-	* Notes that have no votes at all are ranked above notes with 25% or lesser ratings. Notes with greater than 25% ratings are ranked above notes with no votes at all.	+	* Notes that have no votes at all are ranked above notes with 30% or lesser ratings. Notes with greater than 30% ratings are ranked above notes with no votes at all.
	* There is a slight exception to the rule with notes that have fewer than 4 votes. This way notes can not drop suddenly to the bottom of the page without some fair chance (trying to account for error in small sample sizes).		* There is a slight exception to the rule with notes that have fewer than 4 votes. This way notes can not drop suddenly to the bottom of the page without some fair chance (trying to account for error in small sample sizes).
	* Another exception to the rule is notes submitted on today's date. They're always left at the top for that day to give them a fair chance of exposure as well and hopefully collect a good rating sample.		* Another exception to the rule is notes submitted on today's date. They're always left at the top for that day to give them a fair chance of exposure as well and hopefully collect a good rating sample.