- What does the filament-ip-to-country-flag-column package do?
- It adds a Filament table column that takes an IP address and displays the corresponding country flag and location information. It is designed for admin panels that already store IP addresses and want a quick visual country indicator without changing backend architecture. The column supports flag display, location text, and several display customizations.
- How do I install filament-ip-to-country-flag-column in Laravel?
- Install it with Composer using composer require mohammadhprp/filament-ip-to-country-flag-column. The package registers a Filament column and its frontend assets through Filament's asset pipeline. After installation, confirm assets are registered or published correctly for your exact Filament setup.
- Which Filament and PHP versions does this package support?
- The current release supports Filament 5 and requires PHP 8.2 or newer. You should still validate the package's JS and CSS asset registration against your exact Filament version and deployment environment. Older projects should check compatibility before upgrading.
- How do I add an IP to country flag column to a Filament table?
- Use the column in your Filament table definition with IPToCountryFlagColumn::make('client_ip'), replacing client_ip with the attribute that stores the IP address. Basic usage requires only that single column definition. The package then resolves and renders country information for each visible IP cell.
- How can I customize flag position, location position, separator, or hide city and country?
- Use flagPosition('left') or flagPosition('right') to move the flag, and hideFlag() to remove it. Use location(position: 'above') or location(position: 'below') plus location(separator: '-') to control the location text. hideCity() and hideCountry() let you hide those parts of the location name.
- Why does each IP cell make a separate request in my Filament table?
- The current version resolves IP location asynchronously per cell instead of blocking table rendering on one batch lookup. This improves perceived loading performance but creates an N+1-style request pattern for visible rows. Large tables can therefore generate many requests unless you defer offscreen cells or add caching.
- Does this package cache IP geolocation results?
- The current version does not include built-in response caching, so repeated page views, sorting, filtering, or revisiting tables can trigger repeated lookups. Implement caching inside locationResolver() if you need to reduce API traffic. A proxy or self-hosted geolocation service can also own caching and quota policy.
- How do I handle loading states and errors when the IP lookup fails?
- Use loadingState(), errorState(), and errorStateUsing() to define what users see while a lookup is running or when it fails. retryable() can improve resilience, but aggressive retries can increase API pressure during outages or rate limiting. Define retry limits and fallback text for unknown locations.
- How can I reduce API calls and rate-limit risk in large Filament tables?
- Use whenVisible() to defer lookups for offscreen rows and add caching in locationResolver() to avoid repeat requests. Keep retry behavior limited with backoff at the resolver or application layer. Monitor API error rates and consider pagination or narrower tables for high-volume admin screens.
- What production, privacy, and maintenance concerns should I review before using this package?
- The package depends on the third-party iplocation.com service, so rate limits, downtime, cost exposure, and CSP or asset failures can affect the column. IP-derived country display may still raise GDPR or CCPA considerations, so document that it is used for non-PII purposes. Before production, validate Filament asset registration, own caching and traffic policy, and consider a proxy or self-hosted geolocation alternative.