Symphony.

You could do the merge for us? ;o)

You would just need to merge mblabs changes into andrrr's master branch as mine have all been merged already.

Re the fields: Personally I don't like the fact this extension has had specific field types added that aren't much more than renamed field types that already exist, but with slightly different filtering logic. The logic should have been added to the Number Field for instance.

Looks like @mblabs fork is focussed on adding additional code to the DS and event files to deal with his addition of weight field.

Tricky for me to know which one is used more so I think it's best we focus on @andrrr's repo and get that updated (which I've already done).

So I shall send a pull request later.

Cool. Thanks for the work on the community's behalf!

Just a quick one if people have a moment.

I've been updating the code to 2.3 compatible and thought all was ok until I tried to access the /blueprints/datasource/ and /blueprints/events/ pages.

With Shopping_cart enabled I get the message about value is not a string but NULL coming up. I'm guessing it's related to the Widget class being more strict with requiring numbers to be strings.. and I'm unsure where in the code I would need to make the amends.. I'm thinking the field.price.php may need alterations and am looking for a bit of direction to complete the changes:

Github Fork of Shopping Cart for 2.3 update > field > field.price.php

EDIT

Weirdly, removing the 'website' => false, boolean value from the about function in the Events and Datasource php files fixed it.

Is it wise to be removing the about functions from the Events and Datasource files in future? I know we do it for the extension driver file but wasn't sure whether it is being done for other files within extensions?

Andrew, can you post what the actual error output is, then I can let you know what's causing it.

Symphony Fatal Error: Argument `$href` is not of type `string`, given `boolean`.

An error occurred in C:wampwwwsym23-4symphonylibtoolkitclass.general.php around line 1320

1315                     throw new InvalidArgumentException(__('Enforced type `%1$s` for argument `$%2$s` does not match any known variable types.', array($param['type'], $name)));
1316                 }
1317
1318                 // validate variable type
1319                 if( !call_user_func($validator, $param['var']) ){
1320                     throw new InvalidArgumentException(__('Argument `$%1$s` is not of type `%2$s`, given `%3$s`.', array($name, $param['type'], gettype($param['var']))));
1321                 }
1322
1323             }
1324         }
Backtrace
[C:wampwwwsym23-4symphonylibtoolkitclass.widget.php:157]
    General::ensureType();
[C:wampwwwsym23-4symphonylibtoolkitclass.resourcespage.php:211]
    Widget::Anchor();
[C:wampwwwsym23-4symphonycontentcontent.blueprintsdatasources.php:19]
    ResourcesPage->__viewIndex();
[C:wampwwwsym23-4symphonylibtoolkitclass.administrationpage.php:602]
    contentBlueprintsDatasources->__viewIndex();
[C:wampwwwsym23-4symphonylibtoolkitclass.administrationpage.php:559]
    AdministrationPage->__switchboard();
[C:wampwwwsym23-4symphonylibtoolkitclass.administrationpage.php:413]
    AdministrationPage->view();
[C:wampwwwsym23-4symphonylibcoreclass.administration.php:228]
    AdministrationPage->build();
[C:wampwwwsym23-4symphonylibcoreclass.administration.php:381]
    Administration->__buildPage();
[C:wampwwwsym23-4index.php:25]
    Administration->display();

The about function in the event and datasource php files seemed to be part of the problem.. there were boolean declerations for the website entry in the array.. having removed them all seems well.

Just change them to an empty string then, that'll fix it.

If I remember right, 2.3 is a lot less forgiving of errors.

Is it wise to be removing the about functions from the Events and Datasource files in future? I know we do it for the extension driver file but wasn't sure whether it is being done for other files within extensions?

Just for extensions, other assets rely on the about methods being present... although I find them pretty useless in the age of source control.

Ok cool, I'll change to empty string for now.

No response on pull request as of yet :(

A note on the price field: it rejects anything with more than two decimal places, which is potentially a problem if you're storing prices pre-tax (and in other situations such as converting currencies). I believe the minimum number of decimal points that currency should be stored in these situations is 4.

It's not a problem for my usage, though.

@designermonkey:

This is on of the extensions I'd like to involve with the Symphonists (Community extension maintenance), just got to get to this one on the list.

@moonoo2:

No response on pull request as of yet :(

Is this extension going to be added to the Symphonists GitHub account, with @moonoo2's fork being the version that's picked up? I ask because I have a small fix and guess I should send a pull request to @moonoo2 as @andrrr doesn't seem to be maintaining it at the moment.

Another question - sorry. :-)

@moonoo2, does your updated version still work with Symphony 2.2.5?

Anything updated to 2.3 will not work in 2.2.5, especially if the about() function is removed.

I'll Check later @DavidOliver. I'm pretty sure it's a no.

So how long do we wait before realistically taking control or announcing that we'd like to take responsibility for the repo moving forward? Is there an alotted time frame that is usual to wait for response for pull request etc? Just asking :)

We should really clean this one up, especially remove the price field (as proposed by @designermonkey).

I may use it in a Symphony 2.2.x project. In this case I might do some basic work. But I am not sure how fast I will update this project to Symphony 2.3.

Ok, move made. I've forked this to symphonists, and given Andrew push and pull access, Michael already has it.

Andrew, if you want to pull request your changes, we'll all take a look and then you can merge them. I intend to do some work on this too soon.

@moonoo2: I've seen your giant pull request. Your work should be based on the main repo, not on this custom fork. Do you think you can do this?

I created two new branches, integration (to clean up) and 2.3.x (to fix 2.3.x compatibility, ideally a bit later).

Please tell us what you think about removing the price field. Should it use the Number Field instead? Or is a "basic cart" (which is what the extension aims to provide) simply a matter of items and numbers, without prices? Personally I like the latter idea because it's reduced to the essence, but it means that you would have to add prices to your section yourself using the Number Field, for example, and do any price calculations (sums, totals) in the templating layer.

I have recently been playing around with this extension and if find the calculations done already quite handy to be honest.
And i believe it's not that easy to calculate totals in xslt e.g in this example, how would you calculate the total?

<shopping-cart items="4" total="99.05">
    <item id="186" num="2" sum="39.62" />
    <item id="185" num="1" sum="19.81" />
    <item id="179" num="1" sum="19.81" />
    <item id="178" num="1" sum="19.81" />
  </shopping-cart>

I think it's harder then you would expect and can only been done in exslt like @moonoo's solution in this thread...

(or i must have mist something really obvious.. :-)