I finally decided to take the time to integrate my wrapper shown in #106 into mezzanine. The code is far better that way.

One downside though:

======================================================================
ERROR: test_mulisite (mezzanine.core.tests.CoreTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/mathias/PkgBuilding/mezzanine_devel/lib/python3.4/site-packages/django/db/models/fields/related.py", line 303, in __get__
    rel_obj = getattr(instance, self.cache_name)
AttributeError: 'RichTextPage' object has no attribute '_page_ptr_cache'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/mathias/PkgBuilding/mezzanine_devel/mezzanine/mezzanine/core/tests.py", line 238, in test_mulisite
    site1.delete()
  File "/home/mathias/PkgBuilding/mezzanine_devel/lib/python3.4/site-packages/django/db/models/base.py", line 694, in delete
    collector.collect([self])
  File "/home/mathias/PkgBuilding/mezzanine_devel/lib/python3.4/site-packages/django/db/models/deletion.py", line 197, in collect
    field.rel.on_delete(self, field, sub_objs, self.using)
  File "/home/mathias/PkgBuilding/mezzanine_devel/lib/python3.4/site-packages/django/db/models/deletion.py", line 17, in CASCADE
    source_attr=field.name, nullable=field.null)
  File "/home/mathias/PkgBuilding/mezzanine_devel/lib/python3.4/site-packages/django/db/models/deletion.py", line 197, in collect
    field.rel.on_delete(self, field, sub_objs, self.using)
  File "/home/mathias/PkgBuilding/mezzanine_devel/lib/python3.4/site-packages/django/db/models/deletion.py", line 17, in CASCADE
    source_attr=field.name, nullable=field.null)
  File "/home/mathias/PkgBuilding/mezzanine_devel/lib/python3.4/site-packages/django/db/models/deletion.py", line 181, in collect
    parent_objs = [getattr(obj, ptr.name) for obj in new_objs]
  File "/home/mathias/PkgBuilding/mezzanine_devel/lib/python3.4/site-packages/django/db/models/deletion.py", line 181, in <listcomp>
    parent_objs = [getattr(obj, ptr.name) for obj in new_objs]
  File "/home/mathias/PkgBuilding/mezzanine_devel/lib/python3.4/site-packages/django/db/models/fields/related.py", line 320, in __get__
    rel_obj = qs.get()
  File "/home/mathias/PkgBuilding/mezzanine_devel/lib/python3.4/site-packages/django/db/models/query.py", line 307, in get
    self.model._meta.object_name)
mezzanine.pages.models.DoesNotExist: Page matching query does not exist.

I tried to investigate why this is happening but I lack knowledge about the internals of mezzanine and django-modeltranslation. It can be that when models are registered for translation, their managers are not correctly patched but I’m very unsure about this.

Anyway, this issue has a workaround since it happens only when one tries to delete a Site with remaining Pages attached to it. If all pages are deleted beforehand, the Site delete smoothly.

Mezzanine it's a cool django based cms but IMHO lacks of multilanguage support.

Why not integrating a django-app for translating like:

http://code.google.com/p/django-transmeta/

or

http://code.google.com/p/django-modeltranslation/

Upgrade Mezzanine from Bootstrap 2.3.1 to Bootstrap 3.0.2.

This has been merged! Mezzanine is now BS3 compatible. ~~This is still work in progress, I'm opening the ticket to track progress and receive feedback.~~ Struck out items have been completely converted to BS3.

Current status

• ~~Base template~~
• ~~Pages~~
• ~~Navigation menus~~
• ~~Blog~~
• ~~Twitter~~
• ~~Gallery~~
• ~~Forms~~
• ~~Pagination~~
• ~~Search results~~
• ~~Error pages~~
• ~~Ratings~~
• ~~Comments~~
• ~~User panel and accounts~~
• ~~Inline editor~~ (#832)
• ~~Cartridge~~ (https://github.com/stephenmcd/cartridge/pull/146)

Major changes

• Mezzanine now uses two main stylesheets that extend bootstrap.css. First, mezzanine.css adds all necessary tweaks to get BS3 working with the templates. A new file, bootstrap-theme.css, defines extra visual styles for the site, making it look more like BS2. If you want a vanilla BS3 experience, simply remove the latter file from base.html.
• Many class names from BS2 have been modified or removed from BS3. Make sure to check out the migration notes.
• Templates now use more of Bootstrap's classes/hooks instead of implementing separate style solutions, reducing the size of mezzanine.css and necessary markup. It's recommended you become familiar with all Bootstrap components to take advantage of these resources.
• New responsive features and a mobile-first approach are in place, giving more control on how your site displays in different screen sizes.
• The gallery now uses Magnific Popup as image viewer. This results in less markup, responsiveness and keyboard control, among others.

Known issues

• ~~Top menu displays dropdowns on click, not on hover.~~ Commit da1ded9 fixes this one, turns out we don't even need javascript! The problem right now is that mobile users have no way of displaying the dropdown in the responsive nav.

Other bugs found and fixed (not directly related to Bootstrap)

• There is no indication during the sign up process that the account will not be activated right away (assuming settings.ACCOUNTS_APPROVAL_REQUIRED = True). Commits d20ebe6 and 89d65b2 add a message to indicate the situation to the user, similar to what happens already with ACCOUNTS_VERIFICATION_REQUIRED.
• When a user submitted form fails validation (be it by missing required fields or invalid input), only the fields get highlighted with errors, there's no indication at the top of the form on why the submission failed. Commit 323660d addresses this in the same way Cartridge does.
• 500 and 404 error templates used to leave the meta title blank. Fixed in 655b080.

Django 1.11 is out, and it would be great if we could update Mezzanine to support it.

I'm happy to work on a PR but wanted to ask whether we can drop support for Django 1.8 at the same time (it makes life a lot easier if we don't have to maintain compatibility)?

In the spirit of "Mezzanine is just Django" I think we should update the project layout to match Django's default, and go through the project template's settings.py to see if any of the Django defaults need updating.

I'm volunteering to do the work; just opening the issue here to get consensus.

Related issue: #1928

This PR adds support to Mezzanine for Django 2.2. I've used some of the code from @khadegd 's August fork but tried to stay away from the more major changes such as the bootstrap version bump.

Features:

• Working keywords fields
• Working drag and drop inlines
• URLs in 2.0 format

Notes:

• Removed references to Python 2 (since Django no longer supports it)
• Since Django 1.11 will be unsupported in April this PR is only compatible with Django 2.2+
• I've updated Tox to only support Python 3.6+ and Django 2.2+, it will obviously fail with the django master branch since that is now at version 3.
• Also requires an update to grappelli-safe and filebrowser-safe for inlines to work correctly.

Now that the Django 1.6 beta has been released, Mezzanine should start supporting it.

I get this error in a newly-created project:

Environment:


Request Method: GET
Request URL: http://localhost:8001/

Django Version: 1.6b1
Python Version: 2.7.3
Installed Applications:
('mezzanine.boot',
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.redirects',
 'django.contrib.sessions',
 'django.contrib.sites',
 'django.contrib.sitemaps',
 'django.contrib.staticfiles',
 'mezzanine.conf',
 'mezzanine.core',
 'mezzanine.generic',
 'mezzanine.blog',
 'mezzanine.forms',
 'mezzanine.pages',
 'mezzanine.galleries',
 'mezzanine.twitter',
 'filebrowser_safe',
 'south',
 'grappelli_safe',
 'django.contrib.admin',
 'django.contrib.comments')
Installed Middleware:
('django.contrib.sessions.middleware.SessionMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.middleware.common.CommonMiddleware',
 'django.middleware.csrf.CsrfViewMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware',
 'mezzanine.core.request.CurrentRequestMiddleware',
 'mezzanine.core.middleware.RedirectFallbackMiddleware',
 'mezzanine.core.middleware.TemplateForDeviceMiddleware',
 'mezzanine.core.middleware.TemplateForHostMiddleware',
 'mezzanine.core.middleware.AdminLoginInterfaceSelectorMiddleware',
 'mezzanine.core.middleware.SitePermissionMiddleware',
 'mezzanine.pages.middleware.PageMiddleware')


Traceback:
File "/srv/python-environments/8ed280acde8d7f65/local/lib/python2.7/site-packages/django/core/handlers/base.py" in get_response
  101.                 resolver_match = resolver.resolve(request.path_info)
File "/srv/python-environments/8ed280acde8d7f65/local/lib/python2.7/site-packages/django/core/urlresolvers.py" in resolve
  318.             for pattern in self.url_patterns:
File "/srv/python-environments/8ed280acde8d7f65/local/lib/python2.7/site-packages/django/core/urlresolvers.py" in url_patterns
  346.         patterns = getattr(self.urlconf_module, "urlpatterns", self.urlconf_module)
File "/srv/python-environments/8ed280acde8d7f65/local/lib/python2.7/site-packages/django/core/urlresolvers.py" in urlconf_module
  341.             self._urlconf_module = import_module(self.urlconf_name)
File "/srv/python-environments/8ed280acde8d7f65/local/lib/python2.7/site-packages/django/utils/importlib.py" in import_module
  35.     __import__(name)
File "/home/gavin/mezzanine/foobar/urls.py" in <module>
  8. admin.autodiscover()
File "/home/gavin/mezzanine/mezzanine/boot/__init__.py" in autodiscover
  76.     django_autodiscover(*args, **kwargs)
File "/srv/python-environments/8ed280acde8d7f65/local/lib/python2.7/site-packages/django/contrib/admin/__init__.py" in autodiscover
  29.             import_module('%s.admin' % app)
File "/srv/python-environments/8ed280acde8d7f65/local/lib/python2.7/site-packages/django/utils/importlib.py" in import_module
  35.     __import__(name)
File "/home/gavin/mezzanine/mezzanine/blog/admin.py" in <module>
  62. admin.site.register(BlogPost, BlogPostAdmin)
File "/home/gavin/mezzanine/mezzanine/boot/lazy_admin.py" in register
  22.             super(LazyAdminSite, self).register(*args, **kwargs)
File "/srv/python-environments/8ed280acde8d7f65/local/lib/python2.7/site-packages/django/contrib/admin/sites.py" in register
  92.                     admin_class.validate(model)
File "/srv/python-environments/8ed280acde8d7f65/local/lib/python2.7/site-packages/django/contrib/admin/options.py" in validate
  106.         validator.validate(cls, model)
File "/srv/python-environments/8ed280acde8d7f65/local/lib/python2.7/site-packages/django/contrib/admin/validation.py" in validate
  25.                 getattr(self, m)(cls, model)
File "/srv/python-environments/8ed280acde8d7f65/local/lib/python2.7/site-packages/django/contrib/admin/validation.py" in validate_list_filter
  309.                                 % (cls.__name__, idx, field))

Exception Type: ImproperlyConfigured at /
Exception Value: 'BlogPostAdmin.list_filter[1]' refers to 'keywords__keyword' which does not refer to a Field.

First attempt at this here. Haven't gone over settings or fabfile in detail yet, so I'm sure some things won't work. I also want to update settings to their current defaults in Django, where relevant.

In order to put the project_template in a Django-compatible format, I've renamed local_settings.py.template to just local_settings.py in the project app directory (deploy/local_settings.py.template remains).

This means that .template files are exclusively for the use of the fabfile, which I think is nice. But it changes how tests work, so you'll have to have a look over that and see what you think.

This is with Mezzanine 4.1 and Django 1.9.

First, I tried to inject a non-built-in field (like one of Mezzanine's):

EXTRA_MODEL_FIELDS = (
    (
        "mezzanine.pages.models.Page.featured_image",
        "mezzanine.core.fields.FileField",
        ("Featured Image",),
        {"format": "Image", "blank": True,
         "upload_to": "pages/featured-images",
         "help_text": "Image displayed at the top of this page"},
    ),
)

Then, I tried to create the migration: python manage.py makemigrations pages I got this traceback:

Traceback (most recent call last):
  File "manage.py", line 14, in <module>
    execute_from_command_line(sys.argv)
  File "/home/jerivas/.virtualenvs/derpa/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 353, in execute_from_command_line
    utility.execute()
  File "/home/jerivas/.virtualenvs/derpa/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 327, in execute
    django.setup()
  File "/home/jerivas/.virtualenvs/derpa/local/lib/python2.7/site-packages/django/__init__.py", line 18, in setup
    apps.populate(settings.INSTALLED_APPS)
  File "/home/jerivas/.virtualenvs/derpa/local/lib/python2.7/site-packages/django/apps/registry.py", line 85, in populate
    app_config = AppConfig.create(entry)
  File "/home/jerivas/.virtualenvs/derpa/local/lib/python2.7/site-packages/django/apps/config.py", line 90, in create
    module = import_module(entry)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
  File "/home/jerivas/.virtualenvs/derpa/local/lib/python2.7/site-packages/mezzanine/boot/__init__.py", line 82, in <module>
    fields = parse_extra_model_fields(getattr(settings, "EXTRA_MODEL_FIELDS", []))
  File "/home/jerivas/.virtualenvs/derpa/local/lib/python2.7/site-packages/mezzanine/boot/__init__.py", line 70, in parse_extra_model_fields
    field_class = import_field(entry[1])
  File "/home/jerivas/.virtualenvs/derpa/local/lib/python2.7/site-packages/mezzanine/boot/__init__.py", line 53, in import_field
    return import_dotted_path(fully_qualified)
  File "/home/jerivas/.virtualenvs/derpa/local/lib/python2.7/site-packages/mezzanine/utils/importing.py", line 23, in import_dotted_path
    module = import_module(module_path)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
  File "/home/jerivas/.virtualenvs/derpa/local/lib/python2.7/site-packages/mezzanine/core/fields.py", line 127, in <module>
    settings.PACKAGE_NAME_FILEBROWSER)
  File "/home/jerivas/.virtualenvs/derpa/local/lib/python2.7/site-packages/mezzanine/utils/importing.py", line 23, in import_dotted_path
    module = import_module(module_path)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
  File "/home/jerivas/.virtualenvs/derpa/local/lib/python2.7/site-packages/filebrowser_safe/fields.py", line 17, in <module>
    from filebrowser_safe.base import FileObject
  File "/home/jerivas/.virtualenvs/derpa/local/lib/python2.7/site-packages/filebrowser_safe/base.py", line 22, in <module>
    from filebrowser_safe.functions import get_file_type, path_strip, get_directory
  File "/home/jerivas/.virtualenvs/derpa/local/lib/python2.7/site-packages/filebrowser_safe/functions.py", line 16, in <module>
    from django.contrib.sites.models import Site
  File "/home/jerivas/.virtualenvs/derpa/local/lib/python2.7/site-packages/django/contrib/sites/models.py", line 83, in <module>
    class Site(models.Model):
  File "/home/jerivas/.virtualenvs/derpa/local/lib/python2.7/site-packages/django/db/models/base.py", line 94, in __new__
    app_config = apps.get_containing_app_config(module)
  File "/home/jerivas/.virtualenvs/derpa/local/lib/python2.7/site-packages/django/apps/registry.py", line 239, in get_containing_app_config
    self.check_apps_ready()
  File "/home/jerivas/.virtualenvs/derpa/local/lib/python2.7/site-packages/django/apps/registry.py", line 124, in check_apps_ready
    raise AppRegistryNotReady("Apps aren't loaded yet.")
django.core.exceptions.AppRegistryNotReady: Apps aren't loaded yet.

Importing one of Django's own fields, like IntegerField does not cause the error.

Hi,

I notice that setup.py states that Django 2.0 is currently the highest version supported by Mezzanine. However that version of Django is no longer receives extended support (https://www.djangoproject.com/download/).

https://github.com/stephenmcd/mezzanine/blob/master/setup.py#L54

Your automated tests show that it can work on Django 2.1 though. When are you planning to release a version compatible with Django 2.1+? I'm particularly interested in Django 2.2 support as it's an LTS. What's your schedule?

Hi Stephen,

Latest 1.0.8 fresh PIP install here, when attempting to access the sample gallery the below happens:

UnicodeEncodeError at /gallery/
'ascii' codec can't encode character u'\u0301' in position 101: ordinal not in range(128)Request Method:    GET
Request URL:    http://new.kingstoncleanfreaks.com/gallery/
Django Version: 1.5.dev17871
Exception Type: UnicodeEncodeError
Exception Value:    'ascii' codec can't encode character u'\u0301' in position 101: ordinal not in range(128)
Exception Location: /usr/lib/python2.6/genericpath.py in exists, line 18
Python Executable:  /usr/bin/python
Python Version: 2.6.6
Python Path:    ['/srv/www/django/kingstoncleanfreaks.com/src/django-project',
 '/srv/www/django/kingstoncleanfreaks.com/virtualenv/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg',
 '/srv/www/django/kingstoncleanfreaks.com/virtualenv/lib/python2.6/site-packages/pip-0.7.2-py2.6.egg',
 '/srv/www/django/kingstoncleanfreaks.com/virtualenv/src/django',
 '/srv/www/django/kingstoncleanfreaks.com/virtualenv/lib/python2.6/site-packages',
 '/usr/lib/python2.6',
 '/usr/lib/python2.6/plat-linux2',
 '/usr/lib/python2.6/lib-tk',
 '/usr/lib/python2.6/lib-old',
 '/usr/lib/python2.6/lib-dynload',
 '/usr/local/lib/python2.6/dist-packages',
 '/usr/local/lib/python2.6/dist-packages/setuptools-0.6c11-py2.6.egg-info',
 '/usr/lib/python2.6/dist-packages',
 '/usr/lib/python2.6/dist-packages/PIL',
 '/usr/lib/pymodules/python2.6']
Server time:    Thu, 5 Apr 2012 23:44:40 -0400

Unicode error hint

The string that could not be encoded/decoded was: ils/A´vila,
Error during template rendering

In template /srv/www/django/kingstoncleanfreaks.com/virtualenv/lib/python2.6/site-packages/mezzanine/galleries/templates/pages/gallery.html, error at line 23
ascii13 
14  {% editable page.gallery.content %}
15  {{ page.gallery.content|richtext_filter|safe }}
16  {% endeditable %}
17  
18  <ul class="thumbnails gallery">
19  {% with page.gallery.images.all as images %}
20  {% for image in images %}
21  <li>
22      <a class="thumbnail" rel="#image-{{ image.id }}" title="{{ image.description }}" href="{{ image.file }}">
23          <img class="image-overlay-thumb" src="{{ MEDIA_URL }}{% thumbnail image.file 75 75 %}">
24      </a>
25      <div id="image-{{ image.id }}" class="image-overlay" style="display:none;">
26          <a href="#" class="image-overlay-prev">&larr;</a>
27          <a href="#" class="image-overlay-next">&rarr;</a>
28          <img class="image-overlay-full" src="{{ MEDIA_URL }}{% thumbnail image.file 0 600 %}"><br>
29          <p>{{ image.description }}<br>{{ forloop.counter }} / {{ images|length }}</p>
30      </div>
31  {% endfor %}
32  {% endwith %}
33  </ul>

Traceback Switch back to interactive view

Is there an existing issue for this?

• [X] I have searched the existing Issues

Current Behavior

When you create a new site you pretty much gives you a ready to fill website but it seems the default generic home page is not so easy to change it requires working with configuration files and running some commands.

Issue is that documentation is not sufficient to change the default home page.

Expected Behavior

Home page should be easy to change and instructions should be clear.

Steps To Reproduce

1. Install the app

Environment

- Latest version
- All OSs

Anything else?

The main resource for changing the home page is linked in the generic page it self under: Changing this homepage

However it points out to a section titled "Why isn't the homepage a Page object I can edit via the admin?" which doesn't really contain much information about changing the page but gives hints to get started.

However, the suggested methods has the following issues:

First Method (Template)

It requires to run collect templates python manage.py collecttemplates I figured it by checking a discussion about an issue.

After that you will get a template dir with index.html in it which you can modify I wasn't able to find it in the official guide.

Second Method (Editor page)

It make the page editable in the editor: it requires to disable the default template line:

    #path("", TemplateView.as_view(template_name="index.html"), name="home"),

Enablethis line:

    path("", mezzanine.pages.views.page, {"slug": "/"}, name="home"),

and import mezzinine or import views from mezzanine.pages:

from mezzanine.pages import views

and modify path to the following:

    path("", views.page, {"slug": "/"}, name="home"),

This was not in the official guide.

I find instructions after searching for sometime inside one of the closed issues and modified it to my needs.

urls.py file in project dir contains some hints but also missing some vital information.

Is there an existing request for this?

• [X] I have searched the existing Issues

Current problem or need

I'm trying to bring back to life a personal mezzanine site that was running a few years ago, and while I'm doing it I'm updating it's dependencies to the current versions.

While trying to get this site running locally on a development system I've found the "python manage.py migrate" was warning about missing migrations:

Your models in app(s): 'blog', 'conf', 'core', 'forms', 'galleries', 'generic', 'pages' have changes that are not yet reflected in a migration, and so won't be applied.
  Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them.

If I ran python manage.py makemigrations blog then a 0004_auto_20220626_0447.py file was created in the virtualenv site-packages for mezzanine/blog/migrations. Now I'm not an experienced django developer, but that doesn't seem correct.

I found this to occur with django 4.0.6. I found this to occur if I had django 3.2.13 and if I also had DEFAULT_AUTO_FIELD = "django.db.models.BigAutoField".

I've been able to avoid this happening if I use django 3.2.13 and set DEFAULT_AUTO_FIELD = "django.db.models.AutoField"

Desired solution

I guess my desired solution is django 4.0 support, but I can see #2009 was done 6 months ago, so I'm not sure why I'm seeing this, but other people seem to have had success with django 4.0?

I wonder if a solution would be to have someone create migrations within mezzanine with DEFAULT_AUTO_FIELD set to django.db.models.BigAutoField, so that the next release of mezzanine includes these migrations. But I have no idea what that does to backwards compatibility.

Alternatives you have considered

No response

Anything else?

I considered this might actually be my fault, so I used mezzanine-project to create a new project. That project was showing the same behaviour. Here is the output of that:

cooke:~ geoffc$ mezzanine-project test_mezzanine_project
cooke:~ geoffc$ cd test_mezzanine_project/
cooke:test_mezzanine_project geoffc$ python manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, blog, conf, contenttypes, core, django_comments, forms, galleries, generic, pages, redirects, sessions, sites
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying auth.0010_alter_group_name_max_length... OK
  Applying auth.0011_update_proxy_permissions... OK
  Applying auth.0012_alter_user_first_name_max_length... OK
  Applying sites.0001_initial... OK
  Applying blog.0001_initial... OK
  Applying blog.0002_auto_20150527_1555... OK
  Applying blog.0003_auto_20170411_0504... OK
  Applying conf.0001_initial... OK
  Applying core.0001_initial... OK
  Applying core.0002_auto_20150414_2140... OK
  Applying django_comments.0001_initial... OK
  Applying django_comments.0002_update_user_email_field_length... OK
  Applying django_comments.0003_add_submit_date_index... OK
  Applying django_comments.0004_add_object_pk_is_removed_index... OK
  Applying pages.0001_initial... OK
  Applying forms.0001_initial... OK
  Applying forms.0002_auto_20141227_0224... OK
  Applying forms.0003_emailfield... OK
  Applying forms.0004_auto_20150517_0510... OK
  Applying forms.0005_auto_20151026_1600... OK
  Applying forms.0006_auto_20170425_2225... OK
  Applying galleries.0001_initial... OK
  Applying galleries.0002_auto_20141227_0224... OK
  Applying generic.0001_initial... OK
  Applying generic.0002_auto_20141227_0224... OK
  Applying generic.0003_auto_20170411_0504... OK
  Applying pages.0002_auto_20141227_0224... OK
  Applying pages.0003_auto_20150527_1555... OK
  Applying pages.0004_auto_20170411_0504... OK
  Applying redirects.0001_initial... OK
  Applying redirects.0002_alter_redirect_new_path_help_text... OK
  Applying sessions.0001_initial... OK
  Applying sites.0002_alter_domain_unique... OK
cooke:test_mezzanine_project geoffc$ python manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, blog, conf, contenttypes, core, django_comments, forms, galleries, generic, pages, redirects, sessions, sites
Running migrations:
  No migrations to apply.
  Your models in app(s): 'blog', 'conf', 'core', 'forms', 'galleries', 'generic', 'pages' have changes that are not yet reflected in a migration, and so won't be applied.
  Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them.
cooke:test_mezzanine_project geoffc$ python manage.py makemigrations blog
Migrations for 'blog':
  /Users/geoffc/.pyenv/versions/3.10.4/envs/geoff-blog/lib/python3.10/site-packages/mezzanine/blog/migrations/0004_auto_20220626_0509.py
    - Alter field id on blogcategory
    - Alter field id on blogpost

Is there an existing issue for this?

• [X] I have searched the existing Issues
  • This is related to, but not the same as, issue #2022
  • This is related to, but not the same as, the issue of broken links on https://pypi.org/project/Mezzanine/ which I reported over e-mail April 10, 2022 since there was no link to this repo there.

Current Behavior

• The readme was changed to use the github page to replace the domain, but sub-urls such as are still broken.
  • When you click a link in the readme, a GitHub 404 page appears.
  • It looks bad for the project.
  • If the links are erased from the readme, the readme is less useful. Where to find the information from the broken links is unclear.
• When you click any of several Google results (such as https://github.com/stephenmcd/mezzanine/docs/packages.html) about how to use mezzanine, a GitHub 404 page appears.
  • Google tracks this type of thing, so it will harm the ranking of your domain.

Expected Behavior

• Get the helpful information from the search result of readme somehow.
• Make Google links work to prevent the domain from being downranked.

I didn't know where the official repo was so I mentioned over e-mail that https://pypi.org/project/Mezzanine/ had bad links. That was fixed since then. However, the following from my e-mail still remains true regarding the "Current Behavior" above:

. . . https://jupo.org/ [says] ERR_CERT_COMMON_NAME_INVALID.

Do you need hosting? I can probably host this for free on one of my VPSs if you think the site won't be overloaded with traffic, and throw in a domain. I can also help with configuring the domain properly such as using a free cert from https://letsencrypt.org/

I hope this helps.

I would like the site back not just so I can use it but also so I can use a tool that has a community of support rather than appearing abandoned. I'm trying to fix the old ninja-ide website and want to make it work with the latest mezzanine. If people don't feel that mezzanine is supported, fewer people will choose it, and therefore fewer people will report issues or submit pull requests. Therefore, even if you provide a URL to me, the site not existing is still a problem.

Plus, I actually want to be able to learn how to do the things to which the readme (used to) link, not just have the links deleted.

Steps To Reproduce

1. Click any link in the readme or via a search engine that have a "/" after the main site.
2. A 404 error is displayed (and in the case of search results, the error is reported to the search engine for any search engine that uses click tracking such as Google). In the readme, the main site is now the repo, but on Google, the domain redirects to the repo, yielding the same result. The bad cert on jupo.org may also downrank the domain.

Environment

- Operating System: N/A
- Python version: N/A
- Django version: N/A
- Database engine and version: N/A
- Mezzanine version: N/A

Anything else?

Examples of search engine results where clicking links on the first page will downrank your domain:

• https://www.google.com/search?q=mezzanine+5+django&sxsrf=APq-WBu5X0Un-MYsy_EQlBQuYncA5Q0_ng%3A1650717176415&ei=-PFjYvr4GK-vggfH1J2gAw&ved=0ahUKEwj61LLXmKr3AhWvl-AKHUdqBzQQ4dUDCA4&uact=5&oq=mezzanine+5+django&gs_lcp=Cgdnd3Mtd2l6EAMyBQghEKABOgcIABBHELADOgQIIxAnOgYIABAWEB46BQgAEIYDOgUIIRCrAkoECEEYAEoECEYYAFCoHVjyMmC0NGgEcAF4AIABZ4gB_QWSAQM4LjGYAQCgAQHIAQjAAQE&sclient=gws-wiz
• https://www.bing.com/search?q=mezzanine%205%20documentation&qs=n&form=QBRE&=%25eManage%20Your%20Search%20History%25E&sp=-1&pq=mezzanine%205%20documentation&sc=4-25&sk=&cvid=417941BF500F49FAAB5D3C1E067DD178

Example issue(s) containing links that are now bad, which may lead to issues recurring since people can't find the solution there anymore:

• #1991

Example issue(s) that link to jupo.org which has a bad cert:

• #268
• and every other issue with stephenmcd's signature

Example page(s) that have links to "live demo" that no longer exist (I actually don't know where to find any Mezzanine 5 instance):

• https://github.com/stephenmcd/cartridge

I can't find any documentation on how to set up a mezzanine 5 site other than a page somewhere that said it is now setup the same way as a DJANGO site, which is unclear, because mezzanine isn't DJANGO, so I know steps will differ, but which steps and how? The release's "docs" folder just has rst files which are unformatted and therefore the documents' structure is more difficult to follow visually without a Restructured Text viewer, and I can't click links to other files or have a table of contents even if I get such a viewer.

Discussed in https://github.com/stephenmcd/mezzanine/discussions/2029

Links should now point to https://mezzanine.readthedocs.io/en/latest/