Lalabase
티켓·문서·근무시간·고객대화를 한 곳에 모아 KI로 검색, 소프트웨어 기업 고객 프로젝트용, 오픈소스로 자체 서버·독일 클라우드에 배포
교회를 돕기 위해 존재하는 ChurchCRM, 모든 교회를 위한 무료 오픈소스 도구, 비용·제한 없이 데이터는 여러분의 것
ChurchCRM exists to serve the Church — free, open-source tools for every congregation, in every country, in every language. No fees. No lock-in. Your data.
비즈니스HTML · JavaScriptGitHub @ChurchCRM온라인운영자 미확인
써 보셨어요? 한 번만 눌러 주세요. 로그인은 필요 없어요.
개인 계정의 공개 저장소 소유자는 GitHub로 로그인해 운영자를 확인하고 소개를 직접 관리할 수 있습니다. 관리자 승인은 필요하지 않습니다.
로그인한 뒤 확인 파일을 만들어 이 저장소의 기본 브랜치에 30분 안에 커밋해 주세요. 다른 브랜치나 포크의 파일은 인정하지 않습니다. 파일을 올린 뒤 아래에서 확인하면 관리자 승인 없이 관리할 수 있습니다. 자격을 유지하려면 파일을 남겨 두세요.
로그인이 필요하면 로그인 화면으로 이동합니다. 로그인 후 이곳으로 돌아와 원하는 확인 버튼을 다시 눌러 주세요.
프로젝트 폴더에서 /nomorevibe verify를 실행하면 소유권을 확인하고 소개를 직접 관리할 수 있습니다.
1분 만에 확인하기The ChurchCRM Website
저장소 README에서 가져옴
README 전체를 불러오는 중입니다. 아래는 저장된 발췌입니다.
Official marketing website for ChurchCRM — free, open-source church management software.
This repository implements the approved ChurchCRM marketing strategy. Keep public copy outcome-first: show how ChurchCRM helps churches organize people, groups, events, attendance, giving, volunteers, and related workflows before introducing implementation details. Product claims must be verified against the current CRM application, documentation, and releases.
This repository is the source of truth for the public website:README 전문 보기 ↗Official marketing website for ChurchCRM — free, open-source church management software.
This repository implements the approved ChurchCRM marketing strategy. Keep public copy outcome-first: show how ChurchCRM helps churches organize people, groups, events, attendance, giving, volunteers, and related workflows before introducing implementation details. Product claims must be verified against the current CRM application, documentation, and releases.
This repository is the source of truth for the public website:
The private ChurchCRM/marketing repository owns marketing strategy, research, campaign planning, unpublished drafts, social and email content, and reusable marketing templates. It may define the intent for website work, but Hugo-specific implementation guidance belongs here.
Product claims must be verified against ChurchCRM/CRM; technical instructions belong in ChurchCRM/docs.churchcrm.io.
uglyURLs = true to preserve .html URLs for SEO)# Install Hugo (macOS)
brew install hugo
# Start dev server
hugo server
# Open http://localhost:1313
hugo --minify
# Output in public/
ChurchCRM.io/
├── hugo.toml # Hugo config (8 languages, uglyURLs)
├── content/en/ # English page frontmatter
├── layouts/
│ ├── index.html # Home page
│ ├── demo/single.html # Demo page
│ ├── install/single.html # Install page
│ ├── connect/single.html # Connect / community page
│ └── partials/ # Shared: navbar, footer, head, FABs
├── i18n/ # Translations (en, es, pt, zh, fr, ru, de, ar)
├── static/
│ ├── css/ # Site and editorial design styles
│ ├── images/ # Screenshots
│ └── media/ # Logos, favicons
└── .github/workflows/
└── deploy.yml # Hugo build → GitHub Pages on push to master
| Page | URL | Layout |
|---|---|---|
| Home | / | layouts/index.html |
| Demo | /demo.html | layouts/demo/single.html |
| Install | /install.html | layouts/install/single.html |
| Connect | /connect.html | layouts/connect/single.html |
8 languages are configured: en, es, pt, zh, fr, ru, de, ar.
/, /demo.html, etc.)/de/, /de/demo.html, etc.)i18n/*.toml; page content is in content/{lang}/Blog posts live under content/{lang}/blog/ (example: content/en/blog/).
New posts should use the archetypes/blog.md frontmatter scaffold. Use draft: true while drafting.
A draft may originate in the private marketing repository, but publication happens through a PR here.
After that PR merges, the file under content/{lang}/blog/ is canonical. Correct published content here; do not maintain a second editable copy in the marketing repository.
Frontmatter fields we use: title, date, lastmod, draft, author, description, summary, keywords, tags (max 3), featured_image, and featured_image_alt. Don't set url or slug; the filename sets the permalink (/blog/YYYY-MM-DD-slug.html).
To create a new post quickly: hugo new content/en/blog/YYYY-MM-DD-slug.md and edit the generated file.
Social preview images: every page emits Open Graph and X/Twitter sharing metadata from layouts/partials/social-image.html using this priority:
social_image frontmatter — a dedicated 1200×630 raster used only for link previews (differs from the visible page image when appropriate)featured_image frontmatter — used when no social_image is setstatic/images/social/churchcrm-default-social-1200x630.png for all other pagesThe partial emits absolute HTTPS og:image, og:image:alt, twitter:image, and twitter:image:alt for every page. og:image:width (1200) and og:image:height (630) are emitted only for the site default card, whose exact dimensions are known; custom social_image/featured_image values omit width/height so no incorrect metadata is claimed. Content authors can set social_image (and social_image_alt, which falls back to featured_image_alt then the page title) when a page needs a distinct sharing card. The blog archetype scaffolds all four fields. Do not point either field at an SVG — raster PNG/JPEG/WebP renders reliably across link-preview consumers.
i18n/*.toml; translate keys there for each language (use the i18n/{lang}.toml files).content/{lang}/ — copy content/en/ into a new language folder and translate.hugo.toml already includes the configured languages and uglyURLs = true to preserve .html URLs for SEO.hugo.toml languages section, add an i18n/{lang}.toml, and create content/{lang}/.hugo server -D to preview drafts at http://localhost:1313.hugo --minify produces the static site in public/..github/workflows/deploy.yml) builds the site and deploys to GitHub Pages whenever code is pushed to master.static/css/ (we use Webpixels CSS + custom styles in styles.css); images in static/images/.hugo.toml for your site params, add content under content/, and push to a branch configured to deploy.Screenshots come from the CDN. The /screenshots/ page and the main pages read the captures and manifest.json from params.cdnBase (https://cdn.churchcrm.io) at build time, so new captures appear on the next build. Nothing is copied into this repo. Blog images still live in static/images/.
Push to master triggers the GitHub Actions workflow which:
The live site is at churchcrm.io.
Never future-date a post. Hugo skips it, and nothing rebuilds the site when that date arrives. node scripts/check-blog-listing.mjs (run in CI after hugo --minify) fails if a published post is missing from /blog/.
After merge, check that the deploy run passed and the post appears on https://churchcrm.io/blog/. Pages caches HTML for up to 10 minutes, so hard-refresh first.