Found 60 issues

First time here? πŸ‘‹

Welcome to Find a PR.

Find a PR is an open-source site that is built to help developers find projects so that they can submit their very first pull request.

If you're a contributor looking to find a project to contribute to, feel free to browse through the list below.

If you're a maintainer looking to list your project on Find a PR, you can read how to do this in the documentation.

enhancement help wanted

Hi! If I use this package with my project I has a problem. My package.json has a "git dependency" like this:

{
  "peerDependencies": {
    "package": "git+ssh://git@bitbucket.org/team/project.git"
  }
}

And npm-install-peers breaks.

View more
πŸ‘ 5
JWo1F

JWo1F

18th Dec 2017 @ 08:52

help wanted

Hello,

I noticed that there is an incompatibility with the mbstring polyfill and PHP 8.1 / Alpine Linux, which breaks a lot of my projects as soon as the php81-mbstring is not installed, but php81-iconv is installed:

Example:

Warning: iconv(): Wrong encoding, conversion from "ASCII" to "UTF-8//IGNORE" is not allowed in phar:///var/www/localhost/htdocs/phpstan.phar/vendor/symfony/polyfill-mbstring/Mbstring.php on line 736

It looks like //IGNORE is not accepted since echo iconv('UTF-8', 'UTF-8', 'test'); works, while echo iconv('UTF-8', 'UTF-8//IGNORE', 'test'); doesn't

View more
2 comments πŸ‘ 1
danielmarschall

danielmarschall

7th Jan 2022 @ 00:12

help wanted

Octane Version

2.5.9

Laravel Version

11

PHP Version

8.3

What server type are you using?

Swoole

Server Version

8.3

Database Driver & Version

No response

Description

Wildcard paths like config/**/*.php in the watch array of config/octane.php aren't working properly.

Steps To Reproduce

  1. Install chokidar
  2. Run octane:start --watch (I'm using Swoole)
  3. Modify a file in the config directory. Octane won't restart
  4. Change config/**/*.php to config in the watch array of config/octane.php
  5. Restart Octane server
  6. Modify a file in the config directory. Octane will now correctly restart

Same problem with anything else using wildcards eg. database (try modifying a seeder to test).

View more
5 comments
binaryfire

binaryfire

14th Nov 2024 @ 11:57

help wanted

NotOrm Package

The goal is to make abstract code based on the package notorm to build a new orm system

View more
ambroisehdn

ambroisehdn

15th Jun 2022 @ 12:34

help wanted

I would be good to support normalizer_get_raw_decomposition function that appeared in PHP 7.3. I've tried to implement it but seems that existing decomposition data is already optimized to get the final decomposition. Example test case is available here. Pinging @nicolas-grekas as he is the author of Normalizer polyfill.

View more
4 comments
IonBazan

IonBazan

12th May 2018 @ 23:26

help wanted

Laravel Version

11.42.0

PHP Version

8.4.3

Database Driver & Version

No response

Description

Define a custom attribute with a convoluted name using the Attribute syntax:

Example:

protected function foo1Bar(): Attribute
{
    return Attribute::make(
        get: fn () => 'yay',
    );
}

Accessing a custom attribute is internally done by a snake-to-camel case conversion. So this means both foo1_bar and foo_1_bar will yield the expected value.

However, some features in Eloquent do the inverse by calling upon the attribute cache ($getAttributeMutatorCache): a camel-to-snake case conversion. This means that foo1Bar now only translates to foo1_bar, and not anymore to foo_1_bar even though its value would get returned when retrieving it.

echo $model->foo1_bar; // "yay"
$model->append('foo1_bar');
$model->toArray(); // Works fine.

echo $model->foo_1_bar; // "yay"
$model->append('foo_1_bar');
$model->toArray(); // Call to undefined method Model::getFoo1BarAttribute() 

On the contrary, when resorting back to the good old getFoo1BarAttribute() everything works as expected for both foo1_bar and foo_1_bar.

protected function getFoo1BarAttribute()
{
    return 'yay';
}
echo $model->foo1_bar; // "yay"
$model->append('foo1_bar');
$model->toArray(); // Works fine.

echo $model->foo_1_bar; // "yay"
$model->append('foo_1_bar');
$model->toArray(); // Works fine.

So, because of internal two-way case conversions to support the newer attribute syntax some unexpected and disfunctional ambiguity gets introduced.

I think both syntaxes (Attribute vs getXXXAttribute()) should behave equally. But I'm not quite sure how to proceed with this. Should foo_1_bar get blocked for access to prevent this kind of expectations further down the line? Or should it also resolve properly when doing the camel-to-snake conversion? Or...?

Steps To Reproduce

protected function foo1Bar(): Attribute
{
    return Attribute::make(
        get: fn () => 'yay',
    );
}
$model->append('foo_1_bar');
$model->toArray();
View more
4 comments
Propaganistas

Propaganistas

11th Feb 2025 @ 20:29

enhancement help wanted

Let's try out Filament and move our own admin panels to it. This should provide us with a much more powerful admin backend.

https://filamentphp.com

View more
12 comments πŸ‘ 1
driesvints

driesvints

22nd Dec 2023 @ 09:06

help wanted

Hi,

With the polyfill, var_dump(mb_strlen(chr(254))) return 0. With the php8.0-mbstring extension, var_dump(mb_strlen(chr(254))) return 1;

versions : * v1.26.0

Thanks, Alex

View more
7 comments
alexchuin

alexchuin

18th Oct 2022 @ 12:51

help wanted

Octane Version

v2.3.10

Laravel Version

v11.6.0

PHP Version

v8.3.6

What server type are you using?

FrankenPHP

Server Version

v1.1.4 PHP 8.3.6 Caddy v2.7.6

Database Driver & Version

Postgress

Description

Last week we updated our app previously using php-fpm running on Forge to use Laravel Octane with FrankenPHP. Our site is mostly an API that handles analytics events (Like google analytics). It uses the default Laravel api throttling.

In staging our app worked fine (30 req/sec same IP), but when deploying to production (1400 req/sec, different IPs) it started to fail, giving a lot of 429 Too Many Requests.

image

I quickly rolled back to php-fpm and after a few hours tried again with the same problem. Rolled back and the next day I switched to Swoole and it worked perfectly without changing a single line of code nor having to redeploy anything. So I can confidently say that is NOT a bug in my code, but rather a bug with FrankenPHP or the Octane integration with FrankenPHP.

My theory is that the RateLimiter is not reseting between requests so it's shared between different users. So multiple different users trigger the rate limiter:

This is my Rate limiter configuration:

// AppServiceProvider

RateLimiter::for('api', function (Request $request) {
    return Limit::perMinute(60)->by($request->user()?->id ?: $request->ip());
});

our production CACHE_STORE is redis. Throttling worked perfectly fine without octane and with octane but using Swoole. It failed with hundred of 429 Too Many Requests after installing FrankenPHP.

This is our bootstrap/app.php:

<?php

use Illuminate\Foundation\Application;
use Illuminate\Foundation\Configuration\Exceptions;
use Illuminate\Foundation\Configuration\Middleware;
use Illuminate\Support\Facades\App;

return Application::configure(basePath: dirname(__DIR__))
    ->withRouting(
        commands: __DIR__.'/../routes/console.php',
        health: '/up',
        then: function () {
            Route::middleware('api')
                ->prefix('api')
                ->as('api.')
                ->domain(config('app.domain'))
                ->group(base_path('routes/api.php'));

            Route::middleware('web')
                ->domain(config('app.domain'))
                ->group(base_path('routes/web.php'));

            Route::middleware('web')
                ->domain(config('playsaurus.ads.domain'))
                ->group(base_path('routes/ads.php'));
        }
    )
    ->withMiddleware(function (Middleware $middleware) {
        $middleware->throttleApi();

        $middleware->redirectTo(
            guests: '/login',
            users: '/',
        );

        $middleware->web(append: [
            \App\Http\Middleware\HandleInertiaRequests::class,
            \Illuminate\Http\Middleware\AddLinkHeadersForPreloadedAssets::class,
        ]);

        $middleware->api(append: [
            \App\Http\Middleware\ConfigureLocale::class,
        ]);

        $middleware->alias([
            'localize' => \App\Http\Middleware\ConfigureLocale::class,
            'embed' => \App\Http\Middleware\AllowsEmbeding::class,
        ]);
    })
    ->withExceptions(function (Exceptions $exceptions) {
        $exceptions->dontReport([
            \App\Services\Announcements\InvalidVariantKey::class,
            \App\Exceptions\CouponRedeemException::class,
        ]);
    })->create();

Steps To Reproduce

It's difficult to reproduce. Because I can't test it in production because that would mean a lot of downtime for our users.

My theory is that it would be possible to reproduce from multiple different IPs. But since I don't have the means to test it, I don't know.

View more
12 comments πŸ‘ 1
jhm-ciberman

jhm-ciberman

14th May 2024 @ 00:15

bug enhancement good first issue

What happened?

I just installed package and complement for AI powered solution. When I create an issue to test it I get :

Capture d'Γ©cran 2024-07-21 125216

I had to change the links function like this to make it work for me:

public function links(): array
{
    $rawText = Str::finish($this->rawText, 'ENDLINKS');

    $textLinks = $this->between('LINKS', 'ENDLINKS', $rawText);

    $textLinks = explode(PHP_EOL, $textLinks);

    $links = [];

    foreach ($textLinks as $textLink) {
        $textLink = str_replace('\\', '\\\\', $textLink);
        $textLink = str_replace('\\\\\\', '\\\\', $textLink);

        $decodedLink = json_decode($textLink, true);

        if ($decodedLink !== null) {
            $links[$decodedLink['title']] = $decodedLink['url'];
        }
    }

    return $links;
}

How to reproduce the bug

When I install the package in my project and use it with AI powered

Package Version

1.0

PHP Version

8.2.14

Laravel Version

11.14

Which operating systems does with happen with?

Windows

Notes

No response

View more
2 comments
bestmomo

bestmomo

21st Jul 2024 @ 10:57

documentation help wanted good first issue

Provide updates to new functionalities in the v2 of the package.

View more
kwakuOfosuAgyeman

kwakuOfosuAgyeman

5th Jan 2025 @ 05:45

help wanted

Bug description

Chrome, Firefox, and Safari now support setting the width and height attributes on <source> elements within <picture> elements. You can read more about this in the web.dev article on optimizing CLS. This enhancement allows browsers to better handle layout shifts and varying aspect ratios for responsive images.

How to reproduce

Current Behavior:

Currently, Statamic Responsive Images does not take advantage of this browser capability. As a result, when multiple sources are provided, the appropriate width and height attributes are not applied to <source> elements, which may lead to layout shifts due to varying aspect ratios.

Proposed Enhancement:

Set appropriate width and height attributes on <source> elements based on their aspect ratios.

Benefits:

  • Improved Visual Stability: Reduce Cumulative Layout Shift (CLS) by providing browsers with the correct dimensions upfront.
  • Better Performance: Modern browsers can allocate the correct space for images during page load.
  • Enhanced Responsiveness: Accurately reflect different image aspect ratios for a more consistent user experience.

Environment

Environment
Application Name: local
Laravel Version: 11.41.3
PHP Version: 8.3.16
Composer Version: 2.8.5
Environment: development
Debug Mode: ENABLED
URL: local.test
Maintenance Mode: OFF
Timezone: Europe/Paris
Locale: en

Cache
Config: NOT CACHED
Events: NOT CACHED
Routes: NOT CACHED
Views: NOT CACHED

Drivers
Broadcasting: null
Cache: file
Database: sqlite
Logs: stack / single
Mail: smtp
Queue: redis
Session: file

Statamic
Addons: 3
Sites: 1
Stache Watcher: Disabled (auto)
Static Caching: Disabled
Version: 5.46.1 PRO

Statamic Addons
rias/statamic-redirect: 3.9.3
spatie/statamic-responsive-images: 5.2.1
statamic/seo-pro: 6.5.0

Installation

Fresh statamic/statamic site via CLI

Antlers Parser

regex (default)

Additional details

Leveraging native width and height support on <source> elements can lead to significant improvements in layout stability and overall performance on modern browsers. This enhancement would allow the package to better handle responsive images by using up-to-date browser capabilities.

Thanks for considering this enhancement!

View more
2 comments
jimblue

jimblue

7th Feb 2025 @ 22:03

enhancement help wanted
View more
1 comment
driesvints

driesvints

22nd Nov 2024 @ 15:16

enhancement good first issue

using prompt engineering techniques provide enhancement to the Claude service class in the Claude prompt class, creating functions commonly used in Laravel applications. For example, brand builder, seo product optimizer, video and or image captioner, automated chatbots #goodfirstissue

View more
kwakuOfosuAgyeman

kwakuOfosuAgyeman

5th Jan 2025 @ 05:38

good first issue

Dashboard showing Operational

Image

Front end showing no issues, but the status seems to still be linked to the incident even if it's closed as fixed

Image

Image

Image

View more
3 comments πŸ‘ 1
glipschitz

glipschitz

25th Jan 2025 @ 11:01

help wanted

Octane Version

2.6.2

Laravel Version

11.16.0

PHP Version

8.3.6

What server type are you using?

Swoole

Server Version

5.1.2

Database Driver & Version

No response

Description

Before i start, this is not a duplicate to https://github.com/laravel/octane/issues/903, this is about Swoole. Also large stream responses are fixed with https://github.com/laravel/octane/issues/636, but not this case.

While using Storage::download or Storage::response, laravel is creating a stream response that uses php fpassthru($stream). Somehow the buffering between fpassthru and ob_start does not work, instead it tries to load the full file into the memory. This leads to out of memory errors while downloading very big files.

If i replace the fpassthru with a fread-while-loop it is working as expected.

I can basically make a pull request, but need help with the solution... Is this more a problem in the laravel framework or PHP itself?

Steps To Reproduce

  1. Write a laravel controller that uses Storage::download() to download file with e.g. 1 GB
  2. Call the controller and see the out of memory error
View more
4 comments
NiroDeveloper

NiroDeveloper

24th Jul 2024 @ 11:18

help wanted

Bug description

Currently, the plugin calculates width/height incorrectly when swapping aspect ratios, leading to incorrect HTML output. When changing the aspect ratio of an image, the longest side should remain fixed, and the other side should be calculated accordingly.

How to reproduce

For an image of 3000x1688px as a source:

{{ responsive:image ratio="16/9" md:ratio="9/16" }}

it returns:

<picture>
    <source [...] >
    <source [...] >
    <source [...] >
    <img src="/img/asset/hash/image.jpg?w=3000&amp;h=1688&amp;s=9358bb54be5d388a9a2529a4196dcfc6" alt="" width="3000" height="1688">
</picture>

Now for the same image as source but with:

{{ responsive:image ratio="9/16" md:ratio="16/9" }}

it returns:

<picture>
    <source [...] >
    <source [...] >
    <source [...] >
    <img src="/img/asset/hash/image.jpg?w=3000&amp;h=5333&amp;s=6c5c0bb8447dbd7ff61a692f98b5f46d" alt="" width="3000" height="5333">
</picture>

The calculated aspect ratio is correct, but the dimensions are not. The generated values exceed the original image size.

In this last example, the correct height should be 3000px, and the width should be 1688px to ensure the image stays within its original dimensions.

Environment

Environment
Application Name: local
Laravel Version: 11.41.3
PHP Version: 8.3.14
Composer Version: 2.8.5
Environment: development
Debug Mode: ENABLED
URL: local.test
Maintenance Mode: OFF
Timezone: Europe/Paris
Locale: en

Cache
Config: NOT CACHED
Events: NOT CACHED
Routes: NOT CACHED
Views: CACHED

Drivers
Broadcasting: null
Cache: file
Database: sqlite
Logs: stack / single
Mail: smtp
Queue: redis
Session: file

Statamic
Addons: 3
Sites: 1
Stache Watcher: Disabled (auto)
Static Caching: Disabled
Version: 5.46.0 PRO

Statamic Addons
rias/statamic-redirect: 3.9.3
spatie/statamic-responsive-images: 5.2.1
statamic/seo-pro: 6.5.0

Installation

Fresh statamic/statamic site via CLI

Antlers Parser

regex (default)

View more
jimblue

jimblue

3rd Feb 2025 @ 23:33