본문으로 건너뛰기
버전: 2.x

1.x에서 2.x로 업그레이드

기존 애플리케이션을 Laravel Feeds 1.x에서 2.x로 옮길 때 다음 절차를 따르십시오. 설치된 1.x 버전에 이미 피드 slug나 변경된 생성 제목이 포함되어 있다면 해당 변경을 유지하고 완료한 단계는 건너뛰십시오.

실행 환경 요구 사항​

구성 요소1.x2.x
PHP^8.2^8.4
Laravel 구성 요소^11.0 || ^12.0 || ^13.0^13.0

2.x를 설치하기 전에 애플리케이션의 Laravel 의존성과 웹 애플리케이션, CLI, 스케줄러 및 큐 워커에서 사용하는 PHP 실행 환경을 업그레이드하십시오. PHP 8.2 또는 8.3, 또는 Laravel 11.x 또는 12.x를 사용하는 애플리케이션은 1.x를 유지해야 합니다. 지원되는 환경은 호환성을 참조하십시오.

업그레이드 전​

  1. 현재 애플리케이션 코드, composer.json, composer.lock 및 게시된 config/feeds.php를 저장하십시오. 롤백에 필요한 피드 등록 테이블과 생성 파일을 백업하십시오.
  2. 등록 ID, 제목, 기존 slug, 스케줄 및 출력 위치를 기록하십시오.
  3. 배포 스크립트, cron 작업, 수동 스케줄, 테스트 및 애플리케이션 코드에서 feed:generate 호출을 찾으십시오.
  4. 대표 피드를 생성하고 비교할 수 있도록 출력을 보관하십시오.
  5. 배포 중에는 피드 스케줄을 일시 중지하고 실행 중이거나 큐에 있는 피드 작업을 완료한 뒤 패키지를 교체하고 스키마를 변경하십시오.

업데이트 적용​

composer require dragon-code/laravel-feeds:^2.0 --with-all-dependencies
composer check-platform-reqs

설치된 패키지의 config/feeds.php와 애플리케이션에 게시된 복사본을 비교하고 애플리케이션별 설정을 유지하십시오. --force로 다시 게시하지 마십시오. 해당 복사본을 덮어씁니다.

피드 slug 추가​

PR #287은 단일 피드를 선택하는 값을 데이터베이스 ID에서 Str::slug(title)로 만든 slug로 변경합니다.

패키지의 slug 마이그레이션을 아직 실행하지 않았다면 마이그레이션을 게시하십시오.

php artisan vendor:publish --tag=feeds-migrations

이 명령은 모든 마이그레이션 파일을 게시합니다. 게시된 파일을 검증하고 불필요한 파일을 삭제하십시오.

새 add_slug_to_feeds_table 마이그레이션 파일 이름의 타임스탬프를 애플리케이션의 실제 create_feeds_table 마이그레이션 이후이면서 모든 피드 등록 마이그레이션 이전이 되도록 설정하십시오. 이 순서에서는 migrate:fresh가 등록 정보를 기록하기 전에 slug 열을 추가합니다. 그런 다음 마이그레이션을 실행하십시오.

php artisan migrate

이 마이그레이션은 null을 허용하는 slug 열을 추가하고 소프트 삭제된 레코드를 포함한 기존 제목에서 값을 채웁니다. 기존 제목과 ID는 유지됩니다.

경고

애플리케이션이 이미 자체 slug 열을 사용하고 패키지 마이그레이션이 아직 실행되지 않았다면, 데이터를 채우기 전에 마이그레이션이 실패합니다. 배포 전에 이 스키마 충돌을 해결하십시오. 데이터를 보존하고 해당 열을 사용하는 코드를 수정하지 않은 채 애플리케이션의 열을 삭제하지 마십시오.

php artisan tinker에서 저장된 값을 확인하십시오.

app(\DragonCode\LaravelFeed\Queries\FeedQuery::class)
    ->all()
    ->get(['id', 'title', 'slug']);

선택에 사용하는 slug는 비어 있지 않아야 하며, 비활성 등록을 포함하여 삭제되지 않은 등록 간에 서로 달라야 합니다. 서로 다른 제목도 같은 slug로 정규화될 수 있습니다. 여러 등록이 일치하는 조회는 MultipleRecordsFoundException을, 알 수 없는 slug는 FeedNotFoundException을 발생시킵니다. 피드 모델을 통해 제목을 수정하여 slug 충돌이나 빈 값을 해결하십시오.

2.3.0의 PR #334는 fireModelEvent() 재정의를 FeedObserver::saving()으로 대체합니다. 이전에는 조용한 저장을 포함하여 saving, creating, updating 이후 원시 속성으로 slug를 계산했습니다. 이제 saving 옵저버 실행 시 accessor를 거친 제목을 사용하며, 조용한 저장은 건너뛰고 이후 리스너도 재계산을 유발하지 않습니다.

PR #335는 $feed->isDirty('slug') 검사를 추가합니다. 명시적으로 변경한 slug는 Str::slug()으로 정규화되며, title을 함께 변경해도 현재 저장에서는 유지됩니다. FeedQuery::create()에는 extra: ['slug' => 'Custom Catalog']로 전달할 수 있습니다. 변경되지 않은 slug는 여전히 title에서 생성되므로 이후 일반 저장에서는 이전에 지정한 사용자 지정 slug가 바뀔 수 있습니다. 정규화 결과가 현재 slug와 같은 값을 대입해도 재계산을 막지 못합니다.

이전 1.x 또는 2.x 버전에서 업그레이드할 때는 명시적인 slug 대입, 조용한 저장, 제목 accessor, 이벤트 리스너, 부분 선택, 사용자 정의 casts, 대량 쓰기를 점검하십시오. 저장된 제목과 slug, 이후 일반 저장, slug 조회, 예약 생성을 테스트하십시오. 업데이트 설치만으로 기존 행이 바뀌지는 않지만 다음 일반 저장에서는 제목 변경 없이도 사용자 지정 slug나 accessor에서 생성된 slug가 달라질 수 있습니다. 필요하면 명령과 일정에 고정한 slug를 수정하십시오. 명시적인 slug, 조용한 저장, 리스너 처리는 Eloquent를 참조하십시오.

생성 호출의 ID 교체​

저장된 제목이 Products인 등록 ID 42의 마이그레이션 후 slug는 products입니다.

변경 전:

php artisan feed:generate 42

변경 후:

php artisan feed:generate products

2.x에서 인수는 항상 slug입니다. 숫자로 된 문자열은 더 이상 데이터베이스 ID를 선택하지 않습니다. 인수 없이 php artisan feed:generate를 호출하면 여전히 모든 활성 등록을 처리합니다. --target을 사용하는 경우 등록 인수만 교체하십시오. 대상 키는 그대로 유지합니다.

php artisan feed:generate products --target=42

수동 스케줄과 코드에서 실행하는 명령 호출도 같은 방식으로 수정하십시오. 변경 전:

use DragonCode\LaravelFeed\Commands\FeedGenerateCommand;
use Illuminate\Support\Facades\Schedule;

Schedule::command(FeedGenerateCommand::class, [42])->daily();

변경 후:

use DragonCode\LaravelFeed\Commands\FeedGenerateCommand;
use Illuminate\Support\Facades\Schedule;

Schedule::command(FeedGenerateCommand::class, ['products'])->daily();

수동 스케줄의 기존 중복 실행 방지, 백그라운드 실행 및 빈도 설정을 유지하십시오. 등록 이름을 변경할 때는 코드에 직접 지정된 slug도 수정하십시오. ScheduleFeedHelper::register()는 저장된 slug를 자동으로 사용하며, 제목이나 cron 표현식이 변경되어도 중복 실행 방지 잠금을 해당 등록에 연결된 상태로 유지합니다.

FeedQuery::find(int $id), delete(int $id) 및 restore(int $id)는 여전히 ID를 사용합니다. slug로 선택할 때는 FeedQuery::findBySlug(string $slug)를 사용하십시오. 생성 및 스케줄을 참조하십시오.

생성된 제목 확인​

PR #293은 make:feed가 새 등록 마이그레이션이나 배포 작업에 기록하는 제목에서 Feed 접미사를 제거합니다.

php artisan make:feed ProductsFeed를 실행하는 경우:

값변경 전변경 후
생성된 등록 제목Products FeedProducts
해당 제목에서 만든 slugproducts-feedproducts

기존 데이터베이스 제목과 이전에 생성된 등록 파일은 다시 작성되지 않습니다. 각 등록에 실제로 저장된 slug를 계속 사용하십시오. 이 제목 변경으로 피드 클래스 이름과 출력 파일 이름은 바뀌지 않습니다.

문서 및 패키지 개발​

PR #294은 문서 페이지 이름을 머신 러닝에서 AI 에이전트로 변경합니다. 페이지는 이제 /ai-agents/에서 제공되며, 리디렉션으로 이전 URL의 링크도 계속 작동합니다.

PR #297은 새 실행 환경 요구 사항을 설정하고 1.x 문서를 보존합니다. 설치된 패키지와 일치하는 문서 버전을 선택하십시오. 검색 결과와 LLM 컨텍스트는 해당 버전으로 제한됩니다.

패키지 자체 개발 환경은 Pest ^5.0 및 Testbench ^11.0으로 전환됩니다. Pest 명령은 --tia를 사용하며, CI, 벤치마크 및 스냅샷 업데이트에서 전체 테스트를 다시 실행할 때는 --fresh도 사용합니다. 이는 패키지 개발 의존성이며 애플리케이션 테스트 모음의 요구 사항은 아닙니다.

검증​

  • 애플리케이션에서 구성 캐시를 사용한다면 다시 생성하고, 새 코드로 큐 워커와 장시간 실행되는 스케줄러 프로세스를 다시 시작하십시오.
  • 선택하는 모든 등록에 비어 있지 않고 서로 다른 slug가 있으며, 명령과 수동 스케줄이 해당 slug를 사용하는지 확인하십시오.
  • 사용 중인 각 형식의 피드를 하나씩 생성하십시오. 저장한 1.x 출력과 비교하여 분할 파일 수, 파일 이름 및 대표 출력을 검증하십시오.
  • 사용하는 경우 대상 선택, 자동 및 수동 스케줄, 큐를 통한 생성을 확인하십시오.
  • 사용자 지정 피드 모델, 트랜스포머, 매크로 및 프리셋 하위 클래스를 검증하는 애플리케이션 테스트를 실행하십시오.
  • 스키마와 생성 검증이 통과한 뒤 피드 스케줄과 큐 처리를 재개하십시오.

롤백​

피드 생성을 다시 일시 중지하고 진행 중인 작업을 완료하십시오. 이전 애플리케이션 코드, composer.json, composer.lock, 구성 및 생성 명령을 복원한 다음 호환되는 실행 환경에서 composer install을 실행하십시오.

복원한 1.x 패키지가 이미 slug를 사용하는지 확인한 뒤에만 애플리케이션의 마이그레이션 롤백 정책을 적용하십시오. slug 마이그레이션의 down() 메서드는 해당 열만 삭제하며, 변경된 제목이나 생성 파일을 복원하지 않습니다. 필요한 경우 변경된 등록 데이터와 출력 파일을 백업에서 복원하십시오. 생성을 재개하기 전에 구성 캐시를 다시 생성하고 워커와 스케줄러 프로세스를 다시 시작하십시오.

관련 문서​