Add hero and project information page

[hom3mad3]

Description:

This PR combines two originally separate stories due to their high interdependence:

• [#8765] Redesign frontend: Opener: Image with Aside and detail Project
• [#8766] Redesign frontend & backend - More information page (project detail page)

Hero Project Page

Desktop View	Mobile View

Hero without buttons | Plan Page

Project information page

Contact info section (updated in plan detail and project information)

Changes

• Added new reusable hero snippet template and styles
• Added new project information page
• Cleaned up project_detail.html and plan_detail.html - Hero was adapted to the respective use cases
• Streamlining contact section for maintainability, added a few flags in projects: add contact details flag to ProjectContactDetailMixin adhocracy4#1768
• Restyled follow button

[hom3mad3]

for the plan detail page, we need to replace the content of the with another object (point_label) - again brings the lack of consistency in our naming throughout the apps. probably something to add to a documentation/ set of rules whenever we create a new app/model.

[m4ra]

this is not lack of consistency, but different needs for the plan and project model. Plan have points for geolocation, projects do not have that.

[hom3mad3]

@m4ra Thanks for the feedback — I get that plans and projects have different needs. What I meant by 'lack of consistency' is more about standardizing shared building blocks across models. Right now, they both have a name/title, a description, and sometimes a short description, but we're naming these differently (title vs. name, description vs. details, etc).

It’d be helpful if we kept these core properties consistent across models. That way, the code becomes more predictable and easier to work with while still giving space for each model’s unique specifics. Probably something worth documenting as a guideline for future apps.

[hom3mad3]

In this particular case, we also need to do some frontend magic because the design isn’t aware of the different building blocks. That’s another issue — and honestly, it highlights a bigger problem with how features are designed across the team.

Nowadays, we tend to build websites that are more agnostic of the content, so data models become less rigid and more reusable across the platform, that would also be an argument to unify things a little better.

[vellip]

LGTM, thanks for the large changes! I'd suggest waiting for @m4ra or @partizipation to also have a look regarding the django code.

[m4ra]

That's a biggie indeed! Thanks for all the refactoring @hom3mad3
Few things need still some work. See my inline comments.

[m4ra]

this is not lack of consistency, but different needs for the plan and project model. Plan have points for geolocation, projects do not have that.

[hom3mad3]

That's a biggie indeed! Thanks for all the refactoring @hom3mad3 Few things need still some work. See my inline comments.

@m4ra thank you for going over this long one, and for the super insightful feedback 🤗

[vellip]

Looks good to me. I just left one comment regarding the view. After that feel free to merge, unlees you want to wait for @m4ra ofc.

[vellip]

you can remove this if it's not needed.

I am not sure about the other two functions, they might work as is as well.

    def get_permission_object(self):
        return self.get_object()

is the default afaik

and

    @cached_property
    def project(self):
        return self.get_object()

is not used anywhere, is it?

[hom3mad3]

Cool, it makes the code cleaner! I actually just learned that PermissionRequiredMixin defaults to get_object() for permissions, so I simplified it and kept only the basic settings.

changed based on your suggestions, but needed to merge so there are no blockers and impediments! thanks again 🙏