Hey list! > Hello webmasters, > > I was requested to write email here (apologies for missing that sooner > but my last email didn't get responses because the constant > discussions are probably too time consuming for everyone in their busy > lives so no problem basically, I understand). > > There are few adjustments taking place on the PHP bugs tracker - > application level at the moment. > > Two main things are currently being worked on: > 1.) Bugs categories (a.k.a. packages) [ https://bugs.php.net/bug.php?id=78036 > | https://bugs.php.net/bug.php?id=78036 ] (how good that can be done depends > on many things but plan is to move > the categories to static configuration-alike layer instead of the > database directly). So, yes we will finally be able to add some new > bug category, or update current ones. > > 2.) Splitting front controllers to the templates: > We have already discussed this thoroughly and integrated a template > engine in the bugs.php.net and now it's time to split all the www/* > front controllers gradually to the template layer and the "controller" > alike code in the files. > > I've also already integrated a data fixtures importer functionality. > So that on localhost installation we have some demo data to work with > and test how the app behaves. Anyone working today with web apps need > to have also some data already in the app so the local installation > behaves as much similar to the production as possible. Kalle alerted > me, that I've missed the discussion about it here, so now that's > already done and others don't need to invest that more... If it turns > out that we don't need to have demo data on localhost for development, > we'll refactor this more later on. > > For this reason I also use Docker extensively - if someone will want > to use it and install it locally: [ https://github.com/petk/bugs.php.net | > https://github.com/petk/bugs.php.net ] Next steps depend here on multiple > things. > > My suggestion here is very basic actually for now: > - make code more OOP-alike (mainly the functions usage migrated to classes) > - add more tests > - and finally getting to fix the current opened bugs (there are quite > many and some are not very trivial without some changes in the code - > like moving things around, renaming some files etc). > > In case you're interested in the project progress and plan to also > code on it directly, please start following GitHub and pull requests > (anyone's suggestion and contribution is as always welcome): [ > https://github.com/php/web-bugs | https://github.com/php/web-bugs ] To not > disorient the progress too much as far as the first two points > are concerned, I'll get forward with those two. > > Thanks and have a nice day forward. -- > Peter Kokot
I think we can all agree that web-bugs (and some of our other sites) need some love :-) >From what I have seen (besides possible actual improvements for end-users) our sites did not age well. Which is understandable giving the age of sites and the fact that during this time several teams of different people have been working on them. I have been doing some work on bugs lately (mainly in the form of continuing the path set forward as said above (e.g. moving to templating)), but there is more work that needs to be done. For people interested and who not have been following recent development on bugs there are two main (imo big) improvements already done: - there is a unified way now to retrieve data - there is a unified way to render data to the clients The above two things already should make the code base a lot better in time because of the fact that we use prepared statements, have better context based escaping and have better (/ more sane) rendering of client pages (templates). Which makes bugs both more secure and maintainable. I would like to continue working on these specific things in the short term and move the rest of the system over to this where it has not been done yet. At the same time there are several open bugs regarding our bugs site which I also might pick up where possible. Would it be possible for somebody to add bugs.net to the list of packages? This would help categorizing and keeping track of bugs for bugs.net. And maybe people here have ideas / suggestions about bugs.net in which case I would love to hear it! Of course there is *a lot* more room for improvement which is something I would like to handle at a later stage if we all agree there is value in doing this. Pieter -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
