Re: [PHP-DOC] Fixing the layout/style for man pages
I'm not a huge fan of the new design. Like you said I think it's less readable than the current version or than the sphinx version. There's a lot of lost space on the left and on the right. The prototype in the example (even if it's not a function with a lot of params) is not on one line which I think make it really harder to read on the first view. I understand that we don't want to restart everything from scratch so here is what I would do to make it better (from my point of view): - Use 100% of the screen width (instead of the current 75%) move the navigation (layout-menu) on the left of the screen, remove the floating (#quicktoc) to get more space to display usefull content. - Remove margin/padding in a lot of spaces to make it a little bit more compact (and display more data on one screen) - Add the next/previous/up buttons (I don't think there are on the prototype or I can't find them) In my point of view, the current status of the beta site is not usable enough to replace definitivly the current version. One of the good thing about PHP is its documentation and I think it replacing the current one with the prototype will make it less usable and then less enjoyable to read. My 2 cents :) Pierrick On 28 December 2012 16:46, Philip Olson wrote: > Hello everyone, > > What do people think about the PHP manual layout? Let's compare three > versions: > > 1. Current site: > > http://www.php.net/manual/en/function.json-decode.php > > 2. Current prototype (which may launch January 2013): > > http://prototype.php.net/manual/en/function.json-decode.php > > 3. An old example based on sphinx (via Python): > > http://moacirdeoliveira.com/phd/sphinx/function.json-decode.html > > Please sift through these three examples (and maybe others, for other > projects) > and determine how we should proceed. The beta/prototype site will go live > within > a month or two so let's be ready. Let's improve the prototype. > > For me, when evaluating the prototype, this means: > > 1. Improving contrast. The current site hurts my eyeballs. This is why > the sphinx (3) example above is so nice. > > 2. Tighter (less) whitespace, especially for code highlighting. > > Mainly it's the lack of contrast. If given the choice (as a user preference > on the site) I'd use the sphinx version for this reason, although I don't > believe this is a real choice. > > What say you? > > Regards, > Philip >
Re: [PHP-DOC] Contribute to the french PHP doc
Hi all, I'm +1 to give Geoffray an svn account. He created so many bug reports that I asked him to go on edit.php.net to do it himself. https://bugs.php.net/search.php?cmd=display&search_for=&project=&php_os=&php_os_not=&author_email=&bug_type=Documentation+Problem&boolean=0&bug_age=0&bug_updated=0&order_by=id&direction=ASC&limit=30&phpver=&cve_id=&cve_id_not=&patch=&assign=pierrick&status=Closed&reorder_by=id Sorry for the long URL but if you look there's a lot of reports that Geoffray Warnants made and I'm sure he'll help a lot improving the quality of the french documentation. My 0.02 Euros :) Pierrick On 8 December 2011 09:56, Yannick Torrès wrote: > Hi Geoffray, > > I commit a lot of typo from Anonymous on the online editor. > Can you use a google/facebook account that I can follow more easely your > work ? > > Best, > Yannick > > > 2011/12/8 Hannes Magnusson > >> If you know who committed your patches, then just mention her name >> when you register the account. >> If you don't, then you'll have to wait and see if we can figure it out >> ourself. >> In either case, you need to fill out http://php.net/svn-php >> >> -Hannes >> >> On Thu, Dec 8, 2011 at 14:29, Geoffray Warnants >> wrote: >> > Hi, >> > >> > I still got no news from the doc team... is it normal ? >> > >> > Regards, >> > Geoffray >> > >> > >> > 2011/12/4 Hannes Magnusson >> >> >> >> On Sun, Dec 4, 2011 at 11:33, Geoffray Warnants >> >> wrote: >> >> > Dear PHPDoc Team, >> >> > >> >> > I'm Geoffray from Belgium and I used to correct hundreds of minor >> >> > spelling >> >> > misakes in the french manual using edit.php.net and bugs.php.net >> >> > Am I now able to request a SVN account to publish my changes >> directly ? >> >> > I'm >> >> >> >> Definitively, if the people who committed your patches can verify it >> >> your account should get approved within hours. >> >> >> >> -Hannes >> > >> > >> > >
[PHP-DOC] Re: [PHP-CVS] svn: /php/php-src/branches/PHP_5_4/ UPGRADING
I personally think that we should do both. As of 5.4 get_magic_quotes_* are mark them as deprecated to discourage people using it and will always return false. Thanks Pierrick On 22 November 2011 08:29, Peter Cowburn wrote: > Hi docs folks, > > What are your thoughts on how to treat the > get_magic_quotes_(gpc|runtime) functions, in the documentation. > Traditionally we mark functions as deprecated if they're deprecated in > the code (e.g. PHP_DEP_FE), but that's not the case for these two. > > Should we just say in the change log that they'll always return false, > or should the term "deprecated" be used? > > Peter > > On 22 November 2011 13:16, Pierre Joye wrote: >> they are, we only not raise notices or warnings anymore to keep the >> user experience at a good level. So please keep them in here :) >> >> On Tue, Nov 22, 2011 at 2:11 PM, Pierrick Charron wrote: >>> pierrick Tue, 22 Nov 2011 13:11:20 + >>> >>> Revision: http://svn.php.net/viewvc?view=revision&revision=319679 >>> >>> Log: >>> Those functions are not deprecated (r319249 #55371) >>> >>> Bug: https://bugs.php.net/55371 (Closed) get_magic_quotes_gpc() throws >>> deprecation warning >>> >>> Changed paths: >>> U php/php-src/branches/PHP_5_4/UPGRADING >>> >>> Modified: php/php-src/branches/PHP_5_4/UPGRADING >>> === >>> --- php/php-src/branches/PHP_5_4/UPGRADING 2011-11-22 12:47:49 UTC >>> (rev 319678) >>> +++ php/php-src/branches/PHP_5_4/UPGRADING 2011-11-22 13:11:20 UTC >>> (rev 319679) >>> @@ -258,8 +258,6 @@ >>> 7. Deprecated >>> = >>> >>> -- get_magic_quotes_gpc() >>> -- get_magic_quotes_runtime() >>> - mcrypt_generic_end() >>> - mysql_list_dbs() >>> >>> >>> >>> -- >>> PHP CVS Mailing List (http://www.php.net/) >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >> >> >> >> -- >> Pierre >> >> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org >> >> -- >> PHP CVS Mailing List (http://www.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > -- > PHP CVS Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DOC] Stomp extension Documentation
Thanks for you feedback. See my answers bellow 2009/11/7 Israel Ekpo : > > > On Sat, Nov 7, 2009 at 10:44 AM, Pierrick Charron > wrote: >> >> Hi, >> >> I created the documentation related to the stomp extension (I released >> yesterday the version 0.3.0 of it) and i would like to get some >> feedback on this documentation before pushing it online. >> >> You'll find the documentation here : http://php.adoy.net/stomp >> And the XML here : http://www.adoy.net/stomp/doc.tgz >> >> Thanks >> Pierrick > > > Hi Pierrick > > Requirements > > If you want more people to participate in testing/using the extension, I > think you should try to do more regression tests against lower php versions > like 5.2.4 > Most people using PHP are still behind in terms of what they are using the > thier PROD environments. I did some gression tests and the next version 0.3.1 will need PHP >= 5.2.2 instead of 5.2.10 > > Installation > = > You should make the installation instructions clearer instead of sending > them to another page > > Something like: > > ./configure --enable-stomp > > OR > > pecl install stomp-beta > > should be good enough. I added a small section quick install which just provide the pecl install command. Otherwise i prefere people to go to the officiel pecl installation documentation. > > I also thing you should prevent implicit conversion of (void *) when > performing dynamic memory allocation. > > It may cause the C++ based compilers to fail on Windows. I compiled the last version of the stomp extension on windows and it compiled with no error. The only warnings i got are due to php_smart_str.h (which i can't modify) > Examples > > I prefer to use more realistic examples instead of "foo" and "bar". > PHP is used all over the world. Some people may not really follow. > -- > "Good Enough" is not good enough. > To give anything less than your best is to sacrifice the gift. > Quality First. Measure Twice. Cut Once. >
[PHP-DOC] Stomp extension Documentation
Hi, I created the documentation related to the stomp extension (I released yesterday the version 0.3.0 of it) and i would like to get some feedback on this documentation before pushing it online. You'll find the documentation here : http://php.adoy.net/stomp And the XML here : http://www.adoy.net/stomp/doc.tgz Thanks Pierrick