Indeed but I work a full-time job and don't always have the time to explore the intricacies of every issue that's raised. If you think there's a bug with a piece of open source software I would always encourage someone to look at raising a pull request (rather than raising an issue and stopping there). It's also within your power to read all available documentation and to comb through previously closed issues in case your issue has been raised/solved before.

If anything, you learned a little about this library and are better placed to contribute in the future.

fixes https://github.com/u01jmg3/ics-parser/issues/319

When using the iCal Url from outlook the library cannot find the resource. ICal URL: https://outlook.office365.com/owa/calendar/fdb68ce824734d6d9baf8e449812a815@mbgoe.de/d5a7fe4544fc46fb9cc0e734c75301d514870221531791695719/calendar.ics

This is the error i get using it:

Warning: file(https://...@mbgoe.de/d5a7fe4544fc46fb9cc0e734c75301d514870221531791695719/calendar.ics): Failed to open stream: HTTP request failed! HTTP/1.1 400 in /Users/david/projects/churchtools/system/composer/johngrogg/ics-parser/src/ICal/ICal.php on line 2639

I debugged it and this is the code that fails:

I think the file Method cannot deal with the url that has the @ sign in the middle. Putting the URL in Chrome returns the iCal File and also Apple Kalender can use this iCal URL.

Maybe another way to fetch http URLs is necessary here.

Did you see this in the README?

https://github.com/u01jmg3/ics-parser#are-you-using-outlook

This works:

$ical = new ICal('https://outlook.office365.com/owa/calendar/fdb68ce824734d6d9baf8e449812a815@mbgoe.de/d5a7fe4544fc46fb9cc0e734c75301d514870221531791695719/calendar.ics', array('httpUserAgent' => 'A User Agent'));

This is:

- [x] a feature request

• Support Box and Whisker charts

Feel free to submit a PR

👀

Typo

Update Stripe SDK to v7

• Replace Charge::refund() to Refund::create()
• Replace Customer::invoices() to Invoice::all()
• Replace renamed exception classes

Fix removing default payment method

After upgrading to the v7 of the Stripe SDK, the $customer->invoice_settings->default_payment_method is null.

In that case, we don't need to update the Stripe customer, so we will just update the database.

The previous functionality has been kept as is.

Lazy-load the invoice line items

According to #562, the invoice response contains only 10 line items, so we were manually fetching 1000 items.

But Stripe's pagination limit is 100 items, so that doesn't ensure that all the line items will be fetched.

Instead, we can use the Stripe\Collection::autoPagingIterator() which automatically fetches all the paginated results with a generator.

I was tempted to use a lazy collection here, but since this method will be called by the Invoice::invoiceItems() and Invoice::subscriptions() methods, we don't want to hit the API twice just to filter the results.

Configure Stripe logger

Allow users to configure the Stripe library logger using Laravel's logging channels.

By default the Stripe library uses a subset of the PSR-3 logger interface to writes log messages using error_log.

This feature gives users the ability to use Laravel's logging channels instead, by decorating them in a Laravel\Cashier\Logger class, which implements Stripe's logging interface. For more advanced cases, the decorator can accept any PSR-3 implementation.

We can define the desired logging channel name in 3 ways:

1. Using the CASHIER_LOGGER variable in the .env file.

CASHIER_LOGGER=default

2. Otherwise the cashier.logger configuration value can be overriden in the published cashier.php:

'logger' => 'default',

3. Or by calling Cashier::useLogger() in the register method of a service provider:

Cashier::useLogger('default');

Fix payment methods

Merge pull request #784 from sebdesign/stripe-v7

[10.x] Update Stripe SDK to v7

Move logger test

Refactor logger

Fix code style

Refactor handling of invalid webhook signatures

We can rid of the \Illuminate\Contracts\Foundation\Application dependency in the VerifyWebhookSignature constructor, by manually throwing a 403 exception.

This simplifies both the implementation and the tests, and it allows us to pass the message and the original exception to the exception handler.

Merge pull request #791 from sebdesign/feature/invalid-webhook-signatures

[10.x] Refactor handling of invalid webhook signatures

Merge branch 'feature/logger' of https://github.com/sebdesign/cashier into sebdesign-feature/logger

formatting

Remove config repository dependency from webhook middleware

Similarly to #791, we can remove the \Illuminate\Contracts\Config\Repository in the VerifyWebhookSignature's constructor. For consistency, the configuration is accessed with the config() helper like the rest of the code.

Since we don't need to mock the configuration repository anymore, the test has been moved to the integration suite, because we need to bootstrap the framework.

As a bonus, I have added tests for checking replay attacks against the tolerance configuration setting.

Merge pull request #793 from sebdesign/feature/verify-webhook-signature

[10.x] Remove config repository dependency from webhook middleware

Update CHANGELOG.md

Update CHANGELOG.md

version

Update return type

Add findPaymentMethod method

@s0600204, @room34: see b01d72b

Add magic method to support isset() call on dynamic properties Add tests

• PHP Version: 8.2
• PHP date.timezone: America/Chicago
• ICS Parser Version: 3.2.1
• Linux

Description of the Issue:

This pertains to issue #316, which moved all dynamic properties of the Event object into the private additionalProperties array to resolve deprecation notices in PHP 8.2.

Throughout my application I have always liberally accessed Event properties directly, e.g. $event->attach_array, because that approach is used several times in the documentation, and there was not, to my knowledge, a preferred getter method.

Many of these properties apparently were being dynamically defined, which creates deprecation notices in PHP 8.2. So the solution in #316 was to move them into a defined additionalProperties array, and access them using the magic __get() method.

So far so good, but this resulted in a handful of mysterious "disappearances" of data for some of my users, and the resolution requires scouring my code for any instances of a property that might be dynamically defined, and changing those to use the __get() method instead. (Does __get() also work for the defined properties? I suppose it does, but I haven't tested it, because I'm just putting out fires right now.)

Apparently this situation could have been avoided, as it's possible to configure a class to allow dynamic properties, eliminating the deprecation notices in PHP 8.2:

https://php.watch/versions/8.2/dynamic-properties-deprecated#AllowDynamicProperties

I am not specifically requesting a change to this, as I have already made most if not all of the necessary changes in my code. I just wanted to bring this issue to contributors' attention.

Steps to Reproduce:

N/A

Thanks @s0600204

TODO:

• [ ] Create a magic __isset() magic method on the Event class

Thanks for the detailed summary.

I guess we have a few choices.

1. Stick with what we have and create an upgrade guide similar to what @room34 has described
2. Revert #316 and instead use the #[AllowDynamicProperties] comment. We could then later release #316 as a major version bump to the library.
3. ?

@s0600204: what do you think?

Can you raise a new issue explaining the problem and the rewrite that's required? I'm also happy to review another PR

?? can be rewritten as just a standard ternary (is_null($var) ? $var : '')

Thanks for logging this issue. A PR is welcome.

@AEM5299: not sure if it's intentional but your PR no longer has any test coverage.

To note, PHP 8.1+ deprecation warnings are been logged by users (#5603, #5737) which might want to be addressed first before pursuing Laravel 10 support.

Dupe of #5732

Dupe of #5603

Update Rector config

@driesvints: a PR was merged against this issue so perhaps it can be closed now?