PHP 5.3, namespaces, github, composer, packagist

[GoogleCodeExporter]

Hi guys

I love this project, and have used it a few times now. It seems to do a much 
better job of rendering HTML to PDF than TCPDF or any other PHP library I've 
come across.

However, the project looks a little neglected. The code doesn't use namespaces 
(pretty much everyone has dropped support for php 5.2 now, and anyone who does 
is free to use old versions of libraries). The PHP community has largely 
adopted the PSR-0 file naming convention, which specifies a package layout and 
class naming conventions so that everyone can use the same class autoloader.

There are also PSR-1 and PSR-2 conventions, which are gradually stricter on 
coding standards, to help the PHP community move to a consistent coding style 
and make package reuse easier. It would be nice for this package to at least 
support PSR-1 (camel case method names etc) to facilitate better 
interoperability with other libraries and projects. Using these new package 
standards, you could also separate the Cpdf library, which I see is mentioned 
in another bug report here, and mark it as a requirement for the dompdf library.

Also, this is literally the only project I use which is still on google code, 
making it hard for other people to contribute. I realize there is an unofficial 
github mirror, however it's unclear how up to date it is, what the status of it 
is, and also the project is badly laid out in git (with a unnecessary top level 
folder).

Finally, the entire PHP community has pretty much put their weight behind the 
Composer package manager, with packages listed on Packagist.org. Again, I know 
there are some unofficial dompdf packages on there, but it's unclear which one 
to use, how updated they are, and why there is no official package.

Now I'm asking, if I did all the hard work here - create an official github 
project, add PHP 5.3 namespaces, rename all files to match PSR0 naming 
standards, add composer and packagist.org support - would you support it 
officially and continue development there? I'm happy to contribute to this 
project since I've found it so helpful, but there's no point doing all that if 
it's just going to become another unofficial port.

Original issue reported on code.google.com by adr...@crescendo.net.nz on 11 Nov 2012 at 5:06

[GoogleCodeExporter]

Also it would be nice to get some basic PHPUnit testing going on - have you 
looked into that at all? I'm not sure exactly how you would test PDF output, 
but I bet a lot of the internal components and HTML/CSS parsing could be tested 
fairly easily.

One more -1 for google code - It seems I don't even get email notifications to 
these bugs, I didn't see you replied to the comment I made on #543.

Original comment by adr...@crescendo.net.nz on 11 Nov 2012 at 5:14

[GoogleCodeExporter]

Hello, I'm seriously considering a migration to Github. I'm currently learing 
by migrating locally the whole SVN repository to a Github one, and it works 
like a charm.
I'm also aware that DOMPDF uses old habits, like constants for configuration, 
weird file naming, self defined autoloader, no composer/packagist, SVN and PHP 
5.1.

I currently don't have time to handle all this, and migrating to Github to get 
all this in a far easier way is something I should definitely do. So I'm trying 
to do this now.

As of PHP 5.3 compatibility, maybe we should wait the 0.6 release to get all 
this, to have a stable release for people (like me) who need it in old PHP 
installations. I'm more than conscious that PHP 5.1 / 5.2 are really old, so I 
completely understand the need to drop support for them.

And about PHPUnit, I personnaly prefer Atoum, a French still international and 
very active unit testing system. (https://github.com/mageekguy/atoum/) It's 
docs are currently being written. 

Original comment by fabien.menager on 11 Nov 2012 at 9:40

• Changed state: Accepted

[GoogleCodeExporter]

Awesome! Re the move to github, it would make sense to just fork the existing 
shadowhand repo rather than starting a new one (since they have done all the 
work importing from svn already, and other people have already forked it). Then 
clean up the folder naming scheme, for example: 
https://github.com/adrianmacneil/dompdf

If you're looking to add some structure to your git branches, check out git 
flow (http://nvie.com/posts/a-successful-git-branching-model/) and the git 
extension for it (https://github.com/nvie/gitflow).

If you give me access to your github repo I'd be happy to spend some time 
fixing the package layout (remove top level dompdf dir), and migrating/cleaning 
up existing issues from google code.

As you say, probably better to keep the 0.6 branch going with PHP 5.1 support, 
and start a new branch for PHP 5.3 which breaks backwards compatibility.

Original comment by adr...@crescendo.net.nz on 11 Nov 2012 at 11:32

[GoogleCodeExporter]

Oh and I hadn't heard of Atoum, will check it out. But since this is a public 
project, it would probably be better to stick with PHPUnit since pretty much 
one uses & is familiar with it, and this lowers the barriers of entry for 
contributions. Not saying that Atoum might not be great for private/internal 
projects, but if you want to encourage people to contribute then it's good to 
use industry standard tools.

With the github repo - consider creating a github organization (free), so it's 
clear this is the official repo. For example, the repo URL would then be 
https://github.com/dompdf/dompdf

Original comment by adr...@crescendo.net.nz on 11 Nov 2012 at 11:36

[GoogleCodeExporter]

It looks like file history didn't follow the project layout fix on your repo, 
is there a way to change this?

The few forks of shadowhand's repo are all about fixing dependencies and git 
ignore, so I think we can create our own, and then after this, people will fork 
ours.

We'll see with Brian for the unit tests. IMHO, it would be a shame if we don't 
use tools if they are not industry standards, while they are better.

Your URL works now! I created the repo as mine, then transferred ownership 
after creating the dompdf organization.

Original comment by fabien.menager on 12 Nov 2012 at 8:59

[GoogleCodeExporter]

Alright I sorted it all out. Take a look at 
https://github.com/adrianmacneil/dompdf (btw it's always best to completely 
delete github repo and recreate it if you want a clean slate).

The winning command was:

git svn clone http://dompdf.googlecode.com/svn/ dompdf --trunk=trunk/dompdf 
--tags=tags/*/dompdf --branches=branches/*/dompdf

Followed by some manual tagging, then pushing all branches and tags to github. 
Feel free to just clone/fork my one if you can't be bothered. Not sure how 
familiar you are with git, but note that if you want to clone the whole repo 
manually (without using github fork button), you need to pull down each branch 
individually, then push it back up to your new repo.

Also git handles renames pretty differently to svn, it doesn't usually show 
history after a rename, so it's probably not going to matter once you move to 
PSR0 file naming scheme anyway. But at least it's nice to keep the existing 
history.

Original comment by adr...@crescendo.net.nz on 12 Nov 2012 at 11:18

[GoogleCodeExporter]

One more thing - in an ideal world you would run the whole thing through git 
filter-branch and fix your commits so they have your correct email address 
(therefore github matches it to your username). Currently it just has a name 
for all the commits. But it's not a huge deal.

Original comment by adr...@crescendo.net.nz on 12 Nov 2012 at 11:20

[GoogleCodeExporter]

Thanks for the trick ! I actually used "git svn" too, but with different 
--trunk, --tags and --branches values. I'll give a try with your command 
tonight, i'll reset the current repository.
I used a users.txt file, with the name of all the committers to keep the links 
to github accounts.

Original comment by fabien.menager on 12 Nov 2012 at 1:39

[GoogleCodeExporter]

I found a tool that could be helpful to import the issue tracker : 
https://github.com/dave0/gcode-issue-import
Did you already use it ?

Original comment by fabien.menager on 12 Nov 2012 at 9:30

[GoogleCodeExporter]

Everything is in place in the new repository, except for one thing, I did two 
commit/push 

https://github.com/dompdf/dompdf/commit/284b6e4a2ac36334ea04534f45d26a60db536f6f
https://github.com/dompdf/dompdf/commit/4529d5b7be54eec47e35348191252d2ad2412aa5

But they don't appear in the source or the history, what did I don't do ?

Original comment by fabien.menager on 12 Nov 2012 at 10:32

[GoogleCodeExporter]

Nevermind, the web UI took more time to show it than I expected.

Original comment by fabien.menager on 12 Nov 2012 at 10:37

[GoogleCodeExporter]

Awesome! I notice you haven't imported the branches and tags, did you want to 
do that? If you have them locally you can push the tags with git push --tags, 
and the branches you must push one at a time.

Original comment by adr...@crescendo.net.nz on 12 Nov 2012 at 10:44

[GoogleCodeExporter]

Original comment by eclecticgeek on 24 May 2013 at 3:00

• Added labels: Restrict-AddIssueComment-Commit