Select the correct project
Open Google Cloud and select an existing project or create a dedicated project for this WordPress site.
Contest Gallery documentation
Set up Google Sign-In
Create a Google OAuth web client, authorize the exact WordPress origin and connect the Client ID to Contest Gallery.
Contest Gallery 33.xPROGoogle Identity ServicesHTTPS required
Open Google Auth Platform
Use Google Auth Platform inside the Google Cloud project that will own the sign-in configuration. Keep a separate project and Client ID for testing if the production application is already in use.
Google Auth Platform
OAuth clients
Official setup guide
Domain verification
Check the requirements
- The public WordPress site uses HTTPS.
- PHP OpenSSL support is enabled so Contest Gallery can verify Google ID tokens.
- You can manage the Google Cloud project and the production domain.
- The application has a public homepage and privacy policy. Add terms of service when they apply.
- You know the canonical origin that displays the sign-in button, for example
https://www.example.com.
Contest Gallery needs a Client ID, not a Client Secret: Google Identity Services returns an ID token through a browser callback. Do not paste or publish a Google Client Secret.
Create or select the Google Cloud project
Open Google Auth Platform
Use the Auth Platform navigation for Branding, Audience, Clients and Data Access.
Configure branding and application links
Add a clear application name, user support email and developer contact email. For a public application, add the homepage and privacy policy from the same authorized domain. Add terms of service when they apply.
Application name
Use the website or contest name that visitors will recognize on the Google consent screen.
Authorized domain
Add the registrable domain that owns the homepage, privacy policy and terms links.
Logo and verification
A logo or additional OAuth scopes can trigger extra verification requirements. Follow the current Verification Center guidance shown for the project.
Choose the audience and test users
Choose External for a public WordPress site whose visitors can use regular Google accounts. Choose Internal only when sign-in must be limited to users in the same Google Workspace organization.
Stay in Testing first
Keep the app in Testing while setup is incomplete and add every Google account that should test the sign-in flow.
Use minimum data access
For Contest Gallery sign-in, the default identity scopes openid, email and profile are sufficient. Do not add sensitive scopes that the plugin does not use.
Publish after testing
When public visitors should sign in, change the publishing status according to the current Google Auth Platform guidance and complete verification if Google requests it.
Create the OAuth web client
Create a client
Open Clients, choose Create client and select Web application.
Name the client
Use a descriptive name that identifies this WordPress installation.
Add the JavaScript origin
Add the exact HTTPS origin including scheme and hostname, for example https://www.example.com. Do not add a page path.
Leave redirects empty
Contest Gallery uses the Google Identity Services browser callback. It does not require an Authorized redirect URI.
Match the real origin exactly:
https://example.com and https://www.example.com are different origins. Add both only when the sign-in button can genuinely be served from both. Prefer the canonical origin used by WordPress.
Copy the Client ID
Create the web client and copy the value ending in .apps.googleusercontent.com. This public identifier is the only Google credential required by Contest Gallery.
Screenshot safely: A Client ID is not a Client Secret, but unrelated project identifiers, account names and email addresses should still be hidden in public documentation.
Connect Contest Gallery
Open Edit options → Login via Google (general). These settings apply to all galleries. Paste the Client ID, save the options and run Test google client id in combination with your domain.
Frontend shortcode
[cg_google_sign_in] has no gallery ID and can be used once per page.
New WordPress users
A successful first sign-in creates a WordPress user with the role configured in Registration options.
Existing users
The verified Google email is matched safely to WordPress. Custom-domain accounts are linked automatically only when Google confirms the same hosted domain.
Voting and upload access
When configured, Google Sign-In can also appear beside email PIN access for protected voting and frontend uploads.
Test in a private browser window: The Google button is hidden when the current browser session is already logged into WordPress.
Test and publish safely
Run the built-in domain test
Confirm that the saved Client ID works with the exact WordPress origin.
Test the public button
Use an allowed test account in a private window and confirm that the correct WordPress role is assigned.
Verify protected actions
Test every enabled flow such as login, voting, comments and frontend upload.
Move to production
Publish the Google application only after the complete flow succeeds. Complete domain or app verification when Google requests it.
Common setup checks
Button does not appear
Use a private window, confirm that the Client ID is saved and check PHP OpenSSL support.
Origin or redirect mismatch
Compare the browser origin with Authorized JavaScript origins. Remove paths and correct www, scheme or port differences.
Access blocked in Testing
Add the Google account under Audience as a test user or publish the app when it is ready.
Google library blocked
Check consent tools, Content Security Policy and security headers for access to Google Identity Services.