fix: display logo image instead of initials in custom template (#222)

[sivamurugan90428]

Summary

This PR fixes issue #222 — in custom presentation templates, the logo was previously displaying a fallback "i" even after replacing the logo URL.

Now, dynamicSlideLayout.tsx renders the logo as an element when a valid image_url is provided, and falls back to initials only if no image exists.

Changes

• Added dynamicSlideLayout.tsx under servers/nextjs/presentation-templates/custom/
• Updated README.md with instructions for updating logos in custom templates
• Ensured proper rendering of left and right brand logos in the header section
• Maintained decorative waves at the bottom

Testing

• Verified locally using npm run dev
• Confirmed that providing a valid image_url renders the logo image instead of "i"
• Confirmed fallback to initials still works when no image URL is provided

Notes

This update allows template creators to easily replace placeholder logos with custom images and ensures consistent display across templates.

---

Important

Fixes logo rendering in custom templates and adds installation scripts to resolve pyperclip compatibility issues.

• Behavior:
  • dynamicSlideLayout.tsx now renders logo as <img> when image_url is valid, falls back to initials if not.
• Files Added:
  • Added dynamicSlideLayout.tsx under servers/nextjs/presentation-templates/custom/.
• Documentation:
  • Updated README.md with logo update instructions and troubleshooting section for installation errors.
• Scripts:
  • Added install_fixed.ps1 and install_fixed.sh to fix pyperclip installation issue by setting compatible setuptools and pyperclip versions.

^{This description was created by for 86d820c. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed everything up to 86d820c in 2 minutes and 2 seconds. Click for details.

• Reviewed 83 lines of code in 3 files
• Skipped 0 files when reviewing.
• Skipped posting 4 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. README.md:146

• Draft comment:
  The README pins pyperclip to 1.8.2 (i.e. 'pyperclip==1.8.2') but the install scripts use a range (>=1.8.2,<1.9.0). Consider aligning these version constraints for consistency.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% This is a dependency-related comment about version constraints. According to the rules, we should NOT comment on dependency changes or library versions. Additionally, this is a troubleshooting section specifically meant to fix a particular error, so being more restrictive with the version (==1.8.2) might actually be intentional here rather than a mistake. The comment could be valid since inconsistent version specifications across a project can cause confusion. Maybe this will cause problems for users. Per the rules, we should not comment on dependency-related issues. Additionally, this is a specific troubleshooting fix that may intentionally be more restrictive. Delete the comment as it violates the rule about not commenting on dependency changes or library versions.

2. README.md:147

• Draft comment:
  Please add a newline at the end of the file to follow best practices.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While having a newline at the end of files is a common convention, this is a very minor issue. The comment is technically correct, but it's not about logic or functionality. It's more of a style/formatting issue that could be handled by automated tools. According to our rules, we should not make purely informative comments or comments about obvious/unimportant issues. The missing newline could cause issues with some tools or make git diffs less clean. Some would argue this is a legitimate best practice worth enforcing. While true, this is exactly the kind of minor formatting issue that should be handled by automated tooling or pre-commit hooks, not manual code review comments. The comment should be deleted as it addresses a minor formatting issue that doesn't impact functionality and would be better handled by automated tools.

3. scripts/install_fixed.ps1:17

• Draft comment:
  Consider adding error handling (e.g. checking command exit statuses) and ensure the file ends with a newline.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% Error handling in installation scripts is generally good practice, but this is a simple script focused on fixing a specific issue. PowerShell has implicit error handling with $ErrorActionPreference. The newline suggestion is too minor to warrant a comment. The script works as is for its focused purpose. Error handling could prevent silent failures and improve user experience. Missing newlines can cause issues in some environments. While error handling could be nice, this script is intentionally kept simple for a specific fix. PowerShell provides basic error handling by default. The newline issue is too minor. The comment should be removed as it suggests non-critical improvements to a focused fix script, and the suggestions aren't clearly necessary given PowerShell's default behaviors.

4. scripts/install_fixed.sh:1

• Draft comment:
  For better portability, consider using '#!/usr/bin/env bash' instead of the hard-coded '/bin/bash'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The suggestion is technically correct - using /usr/bin/env bash is more portable as it will find bash wherever it's installed on the system. However, /bin/bash is extremely common and works on virtually all Unix-like systems. The change would be a minor improvement at best. The rules say to only keep comments that clearly require a code change. The suggestion might be important for edge cases where bash is installed in a non-standard location. Also, this is a best practice recommended by many shell scripting guides. While technically correct, this change is not critical - /bin/bash works fine on the vast majority of systems. The rules specifically say not to make comments that are purely informative or unimportant. Delete this comment as it suggests an optional improvement that isn't critical enough to warrant a required code change.

Workflow ID: wflow_O3g9oSzKLa1AS8ht

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Consider adding 'set -e' after the shebang to exit immediately if a command fails.

[ellipsis-dev]

Please add a newline at the end of the file for consistency and to avoid potential issues.

[ellipsis-dev]

Typo detected: The command on line 20 reads "gpte projects/example". Should it be "gpt-engineer projects/example" (or the intended command)?

Suggested change

	Write-Host "You can now run: gpte projects/example"
	Write-Host "You can now run: gpt-engineer projects/example"