Upgrade to PHP 7 - String class name and Router issue

[Elena Cenacchi]

Hi,

I'd like to upgrade to PHP 7 and I encountered the String class name error, Since I have not found the updated framework class (similarly to the CMS one)  I decided to rename the class into "StringHelper" and then replaced each "String::", "\String", "/String" occurrence inside the package.

The web application now runs ok but....the routing is not working anymore and it's always going to the Default layout. No error is thrown.

The point is that inside the App.php doExecute function, the line

$controller = $router->getController($this->get('uri.route'));

is always assigning the Default Controller value because $this->get('uri.route') is empty! In fact, if I replace $this->get('uri.route') with the correct routing name (i.e.  $router->getController('test') for url mywebapp/www/test) the page is loaded correctly.

I checked everywhere...the Registry.php get function shows the call to uri.route but then the $this->data object is filled with the config.json data only.  

Does anyone has any suggestion about what I could be missing?

Thanks in advance.

Elena

[Elena Cenacchi]

I found the issue!

Inside registry.php the set function assigned property to objects like this:

 

$node->$nodes[$i] = new \stdClass;

This syntax is probably misinterpreted in PHP 7 (worked fine with PHP 5), so I changed to:

$node->{$nodes[$i]} = new \stdClass

(there are 4 occurruncess inside the function) and now the URI values are set correctly inside the $config Registry object :-)

Elena

[Michael Babker]

You must have some outdated dependencies.  The code was adjusted in 2015 for PHP 7 compatibility and there should be no issues with this.

--
Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
---
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsub...@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-framework.

[Adriano Giovannini]

I have same issue. The 'composer.json' file in starter application require joomla-framework 1.0 which is not compatible with php7.

I tried for a long time but have not found any way to install the framework 2.0 ....

The version that is installed via composer with the project does not contain the class StringHelpers

[Michael Babker]

There is no starter application supported by the project.  So whomever is maintaining that is using outdated resources.

Likewise, a (looking back now terrible) decision was made to not manage the Framework as a monolithic stack but as a semi-independent set of libraries.  As such, the only `joomla/joomla-framework` packages are from December 2013 and February 2014.  All updates since then rely on the individual library repositories.

[Adriano Giovannini]

So it's not a real framework but only set of packages update in 2014?

[Michael Babker]

In the sense that the source code is not found and managed in a single repository, you're correct in that it is not a framework.  However, a framework is really nothing more than a set of tools to help with developing applications, so even though the individual libraries at https://github.com/joomla-framework aren't stored in a single repository as an overall collection it can still be considered a framework.

On Mon, Feb 6, 2017 at 4:01 PM, Adriano Giovannini <wordpr...@gmail.com> wrote:

So it's not a real framework but only set of packages update in 2014?

--

[Adriano Giovannini]

I agree your point of view ...

The question was about updates. The individual packages receive updates when you need it or not?

[Michael Babker]

As long as your Composer manifest is pulling in the correct packages (so not the `joomla/joomla-framework` package but the individual `joomla/*` packages) then you'll get updates as new versions are tagged.  https://github.com/joomla/framework.joomla.org/blob/site-rebuild/composer.json is the Composer manifest for a rebuilt version of the Framework website to give you an idea.

On Mon, Feb 6, 2017 at 4:17 PM, Adriano Giovannini <wordpr...@gmail.com> wrote:

I agree your point of view ...

The question was about updates. The individual packages receive updates when you need it or not?

--

[Adriano Giovannini]

Ok thanks a lot.

[Elena Cenacchi]

Thanks Michael, that was my issue too. After your reply I made some tests and realized that I was not syncing with the updated String package because I was requesting joomla/joomla-framework inside composer.json. Changed that with individual package requests and now I have the PHP 7 updated libraries!

Elena

[Walt Sorensen aka photodude]

On Monday, February 6, 2017 at 2:34:41 PM UTC-7, Michael Babker wrote:

Likewise, a (looking back now terrible) decision was made to not manage the Framework as a monolithic stack but as a semi-independent set of libraries.  As such, the only `joomla/joomla-framework` packages are from December 2013 and February 2014.  All updates since then rely on the individual library repositories.

Michael, how do we get back to managing the Framework as a monolithic stack and not as the semi-independent set of libraries? other than simplifying management, Is there any other benefit to going back to a monolithic stack?

[Michael Babker]

At this point I don't think it's possible without screwing up the existing repositories.  Apparently there are ways where you can recombine git repositories while retaining history, but if we tried to start doing subsplits again into those repositories (this is how you can install the individual components of Symfony versus dragging the whole framework repo in) it would damage the git tags and Composer integrations pretty badly I fear.

I don't see it happening without abandoning the currently dead https://github.com/joomla/joomla-framework repo, the entire https://github.com/joomla-framework organization, all of the existing packages through Packagist, and establishing new architecture with new names that don't collide.  Not worth it to me personally.

--

[piotr_cz]

What are the pros of having one framework repo instead of multiple libraries?

IMHO Joomla framework as a whole is not great, but some libraries are and so I'm pulling these into existing project.

[Michael Babker]

Easier management of the collective resource honestly is the main one.  Easier testing of interdependencies between packages (it's all in one spot and is therefore all tested together).  My entire day yesterday was spent working through each repository on my local checkout three full times (and was starting a fourth) to update all of the test suites for PHPUnit 6.0 compatibility, enabling a testing pass on the PHP master branch (nightly builds), merging all master branch activity into 2.0 branches (and dealing with the various merge conflicts that are coming from that), and working through each package to bump the version constraints to allow 1.x or 2.x installations where practical.  It is not a quick process when dealing with over 40 repositories.

You can still have it all in one repo with the ability to pull in the individual libraries (git subsplit and similar tools exist for that, see how Symfony does it).

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsubscrib...@googlegroups.com.

Visit this group at https://groups.google.com/group/joomla-dev-framework.

[piotr_cz]

I see. Maybe that's why Laravel framework is in one repo.

On Monday, February 20, 2017 at 1:25:33 PM UTC+1, Michael Babker wrote:

Easier management of the collective resource honestly is the main one.  Easier testing of interdependencies between packages (it's all in one spot and is therefore all tested together).  My entire day yesterday was spent working through each repository on my local checkout three full times (and was starting a fourth) to update all of the test suites for PHPUnit 6.0 compatibility, enabling a testing pass on the PHP master branch (nightly builds), merging all master branch activity into 2.0 branches (and dealing with the various merge conflicts that are coming from that), and working through each package to bump the version constraints to allow 1.x or 2.x installations where practical.  It is not a quick process when dealing with over 40 repositories.

You can still have it all in one repo with the ability to pull in the individual libraries (git subsplit and similar tools exist for that, see how Symfony does it).

On Mon, Feb 20, 2017 at 4:46 AM, piotr_cz <pkoni...@hotmail.com> wrote:

What are the pros of having one framework repo instead of multiple libraries?

IMHO Joomla framework as a whole is not great, but some libraries are and so I'm pulling these into existing project.

On Tuesday, February 7, 2017 at 5:39:58 PM UTC+1, Michael Babker wrote:

At this point I don't think it's possible without screwing up the existing repositories.  Apparently there are ways where you can recombine git repositories while retaining history, but if we tried to start doing subsplits again into those repositories (this is how you can install the individual components of Symfony versus dragging the whole framework repo in) it would damage the git tags and Composer integrations pretty badly I fear.

I don't see it happening without abandoning the currently dead https://github.com/joomla/joomla-framework repo, the entire https://github.com/joomla-framework organization, all of the existing packages through Packagist, and establishing new architecture with new names that don't collide.  Not worth it to me personally.

On Tue, Feb 7, 2017 at 10:30 AM, Walt Sorensen aka photodude <wa...@waltsorensen.com> wrote:

On Monday, February 6, 2017 at 2:34:41 PM UTC-7, Michael Babker wrote:

Likewise, a (looking back now terrible) decision was made to not manage the Framework as a monolithic stack but as a semi-independent set of libraries.  As such, the only `joomla/joomla-framework` packages are from December 2013 and February 2014.  All updates since then rely on the individual library repositories.

Michael, how do we get back to managing the Framework as a monolithic stack and not as the semi-independent set of libraries? other than simplifying management, Is there any other benefit to going back to a monolithic stack?

--
Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
---
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsub...@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-framework.

[Michael Babker]

We started with one repo then a decision was made that instead of having more organized releases and a single management structure that each package should have a life of its own and in many ways the concept of an "organized" release was abandoned in favor of just creating a new tag when there are a few new commits in the repo.  For a continuous integration type environment that's not a bad approach.  And if you aren't maintaining a large library of components/packages/libraries/whatever I feel like it would work there too.  But 43 repositories mainly managed by two or three people at best?  That definitely makes resource management much more complex.

On Mon, Feb 20, 2017 at 2:54 PM, piotr_cz <pkoni...@hotmail.com> wrote:

I see. Maybe that's why Laravel framework is in one repo.

On Monday, February 20, 2017 at 1:25:33 PM UTC+1, Michael Babker wrote:

Easier management of the collective resource honestly is the main one.  Easier testing of interdependencies between packages (it's all in one spot and is therefore all tested together).  My entire day yesterday was spent working through each repository on my local checkout three full times (and was starting a fourth) to update all of the test suites for PHPUnit 6.0 compatibility, enabling a testing pass on the PHP master branch (nightly builds), merging all master branch activity into 2.0 branches (and dealing with the various merge conflicts that are coming from that), and working through each package to bump the version constraints to allow 1.x or 2.x installations where practical.  It is not a quick process when dealing with over 40 repositories.

You can still have it all in one repo with the ability to pull in the individual libraries (git subsplit and similar tools exist for that, see how Symfony does it).

On Mon, Feb 20, 2017 at 4:46 AM, piotr_cz <pkoni...@hotmail.com> wrote:

What are the pros of having one framework repo instead of multiple libraries?

IMHO Joomla framework as a whole is not great, but some libraries are and so I'm pulling these into existing project.

On Tuesday, February 7, 2017 at 5:39:58 PM UTC+1, Michael Babker wrote:

At this point I don't think it's possible without screwing up the existing repositories.  Apparently there are ways where you can recombine git repositories while retaining history, but if we tried to start doing subsplits again into those repositories (this is how you can install the individual components of Symfony versus dragging the whole framework repo in) it would damage the git tags and Composer integrations pretty badly I fear.

I don't see it happening without abandoning the currently dead https://github.com/joomla/joomla-framework repo, the entire https://github.com/joomla-framework organization, all of the existing packages through Packagist, and establishing new architecture with new names that don't collide.  Not worth it to me personally.

On Tue, Feb 7, 2017 at 10:30 AM, Walt Sorensen aka photodude <wa...@waltsorensen.com> wrote:

On Monday, February 6, 2017 at 2:34:41 PM UTC-7, Michael Babker wrote:

Likewise, a (looking back now terrible) decision was made to not manage the Framework as a monolithic stack but as a semi-independent set of libraries.  As such, the only `joomla/joomla-framework` packages are from December 2013 and February 2014.  All updates since then rely on the individual library repositories.

Michael, how do we get back to managing the Framework as a monolithic stack and not as the semi-independent set of libraries? other than simplifying management, Is there any other benefit to going back to a monolithic stack?

--
Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
---
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsubscrib...@googlegroups.com.

Visit this group at https://groups.google.com/group/joomla-dev-framework.

--
Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
---
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsubscrib...@googlegroups.com.

Visit this group at https://groups.google.com/group/joomla-dev-framework.

[Andrew Eddie]

On Monday, 20 February 2017 22:25:33 UTC+10, Michael Babker wrote:

Easier testing of interdependencies between packages (it's all in one spot and is therefore all tested together). 

That's actually a really bad reason and is a code smell. One of the reasons for the separate repo's was to ensure that no accidental tight coupling occurred, or, that the coupling because so blatantly obvious that the frustration would lead one to fix it. Individual repos is the best way to manage the code and run the test. With separate package, you bring in the dependencies under the `require-dev` node in composer. 

 

My entire day yesterday was spent working through each repository on my local checkout three full times (and was starting a fourth) to update all of the test suites for PHPUnit 6.0 compatibility, enabling a testing pass on the PHP master branch (nightly builds), merging all master branch activity into 2.0 branches (and dealing with the various merge conflicts that are coming from that), and working through each package to bump the version constraints to allow 1.x or 2.x installations where practical.  It is not a quick process when dealing with over 40 repositories.

Yep it sucks but this is the normal state of affairs. If you are dealing with npm or bower you have the same problems. It just means the project needs to invest in better automated CI tooling (how is up to the project).

I will qualify that be saying that's only important if the desire is still for the framework to be a separate "thing" the project publishes. If there is no motivation to do that anymore, there's actually no point in going to the trouble of having separate repo's for the packages. If the latter is the case, just kill off the framework as a "thing" otherwise people will continue to be confused as to what it is supposed to be and do.

I think your pain points are coming from ideas for the framework that died many years ago.

Regards,

Andrew Eddie

[Michael Babker]

If Joomla were more than a small handful of "long term" (and either burned out or bitter, if not both) with a bigger handful of feature contributors, and would stop using the "we're only volunteers" excuse as a scapegoat for why things don't get done, or even change, honestly I might be more comfortable with where things are at now.  Unfortunately I see Joomla being in a constant state of the user base is big enough it's still healthy to use for 3-5 years but it's core foundation means it will never grow in the ways it needs to in order to remain competitive in a highly evolving market space.

So many good ideas have been allowed to die over the last 5 years because it challenges the status quo.  The result is Joomla is fundamentally the same today as it was in 2011 while the once inferior WordPress is becoming a more viable CMS option (versus its once primary blogging focus) continues to steal websites right and left.

So ya, I'm annoyed, I'm frustrated, and I'm tired.  But I'm still here because people keep sucking me in, so for better or worse I'm going to keep beating dead horses in hopes someone will listen.  If nothing else, I can say I've now found my way to that spot where most "retire" from the project out of.

--

Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
---
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-frame...@googlegroups.com.

Visit this group at https://groups.google.com/group/joomla-dev-framework.

--

- Michael Please pardon any errors, this message was sent from my iPhone.