Error when attempting to manually overwrite a category page

[jminardi]

I am trying to manually overwrite an automatically generated category page (which worked in previous versions) and I get this error:

CRITICAL: File /Users/jack/code/mine/jack.minardi.org/.source/output/projects/index.html is to be overwritten

Which I think was introduced by this commit: ff7410c

Is there any way to go back to the old behavior where I was able to manually write my own page to a category page.

If not, is there a different way to accomplish what I am trying to do?

[visualmotive]

For what it's worth, it seems that enabling the pagination settings as described in the documentation also generates this kind of error.

PAGINATION_PATTERNS = (
    (1, '{base_name}/', '{base_name}/index.html'),
    (2, '{base_name}/page/{number}/', '{base_name}/page/{number}/index.html'),
)

[justinmayer]

Any thoughts on this, @Rogdham?

[jminardi]

Some more information:

You can find my site directory on github: https://github.com/jminardi/jminardi.github.io

I have a category called "projects": https://github.com/jminardi/jminardi.github.io/tree/master/.source/content/projects

And then I attempt to also write a page called projects: https://github.com/jminardi/jminardi.github.io/blob/master/.source/content/pages/projects.md

I added some extra metadata ignore_in_nav so that I wouldn't get duplicate entries there.

[Rogdham]

@jminardi wrote:

Is there any way to go back to the old behavior where I was able to manually write my own page to a category page.

If not, is there a different way to accomplish what I am trying to do?

Looking at your website, it seems that you want to override every category listening.
So I suggest you add the following in your config file: CATEGORY_SAVE_AS = None; I've tried it on your site and it seems to work, but please double check that it is really the case as I haven't looked in details.

---

@justinmayer: good question though: what if someone would like to override only one category?
The idea behind detecting overrides and blocking generation was the following two points:

• users are very likely not willing to override stuff, i.e. it's a bug in their config file
• if two different sources are to write in the same file, how to choose between the two? are we choosing the first one? the second one? what if there are more than two? are we 100% sure the order is deterministic?

So if we want to change that, I think we need to think about those questions carefully.

Just my 2 cents.

---

@visualmotive wrote:

For what it's worth, it seems that enabling the pagination settings as described in the documentation also generates this kind of error.

PAGINATION_PATTERNS = (
(1, '{base_name}/', '{base_name}/index.html'),
(2, '{base_name}/page/{number}/', '{base_name}/page/{number}/index.html'),
)

I can not reproduced that: it seems to work as expected with current master on my side.

[jminardi]

@Rogdham Why does only the "projects" page fail and not the other two? Currently I am overwriting all category pages, however I might not want to in the future.

• users are very likely not willing to override stuff, i.e. it's a bug in their config file

I agree with this. But some users might want to, so as a stop gap it may make sense to implement an ALLOW_FILE_OVERWRITE option in the config file.

• if two different sources are to write in the same file, how to choose between the two? are we choosing the first one? the second one? what if there are more than two? are we 100% sure the order is deterministic?

I agree this is a tough question, and should be considered before anything is implemented. My first idea is to say that manual content should always trump automatic content. I.E. a user defined page should win out over an automatically generated category page. Does this seem feasible?

[DonDebonair]

For what it's worth, it seems that enabling the pagination settings as described in the documentation also generates this kind of error.

PAGINATION_PATTERNS = (
(1, '{base_name}/', '{base_name}/index.html'),
(2, '{base_name}/page/{number}/', '{base_name}/page/{number}/index.html'),
)

I can not reproduced that: it seems to work as expected with current master on my side.

@Rogdham I'm encountering the same issue. Somehow, when using the PAGINATION_PATTERNS setting, it messes up the generation of the tag-pages. I get the following error:

CRITICAL: File /Users/daan/projects/python/dandydev.net/output/tags/index.html is to be overwritten
make: *** [/Users/daan/projects/python/dandydev.net/output/index.html] Error 1

I'm at a loss at what the pagination settings would have to do with the tags page... I hope this can be resolved soon, because otherwise I can't support the new-style pagination (using PAGINATION_PATTERNS) in my theme (see DonDebonair/pelican-bootstrap3#66)

[Rogdham]

I'm encountering the same issue. Somehow, when using the PAGINATION_PATTERNS setting, it messes up the generation of the tag-pages. I get the following erro

And I still can't reproduce :-/

Here is what I've done:

• create a new pelican blog with pelican-quickstart
• add 10 markdown posts (see below)
• modify the setting file with PAGINATION_PATTERNS as described and only allowing 3 articles per page
• generating the blog

Here is an example of such a markdown post:

title: 00
date: 2014-02-10

00
==

00

Here is the full pelicanconf.py file:

#!/usr/bin/env python
# -*- coding: utf-8 -*- #
from __future__ import unicode_literals
AUTHOR = u'Me'
SITENAME = u'Title'
SITEURL = ''
PATH = 'content'
TIMEZONE = 'Europe/Paris'
DEFAULT_LANG = u'en'
FEED_ALL_ATOM = None
CATEGORY_FEED_ATOM = None
TRANSLATION_FEED_ATOM = None
LINKS = (('Pelican', 'http://getpelican.com/'),
     ('Python.org', 'http://python.org/'),
     ('Jinja2', 'http://jinja.pocoo.org/'),
     ('You can modify those links in your config file', '#'),)
SOCIAL = (('You can add links in your config file', '#'),
      ('Another social link', '#'),)
DEFAULT_PAGINATION = 3
PAGINATION_PATTERNS = (
    (1, '{base_name}/', '{base_name}/index.html'),
    (2, '{base_name}/page/{number}/',
    '{base_name}/page/{number}/index.html'),
    )

And with that, no problem to generate, and the link to the first page is as it should be (http://localhost:8000/ so no page number).

@dandydev: Could you test those settings see if we have a coherent behavior, and in any case provide some configuration where you got the error while generating? I would like to reproduce that bug so that I could try to fix it, but obviously I'm missing something here.

[DonDebonair]

I have created a new blog as well, following your instructions. I have the same settings as you have. I don't get an error until I add tags to an article. The combination of having tags and using the PAGINATION_PATTERNS seems to be problematic.

[barraudf]

Hi, i'm also having a hard time making tags, categories and pagination work together. From @Rogdham test senario (fresh quickstart blog with a few sample posts), here are my observations :

• when enabled alone, each of the three features works as intended
• with no pagination, tags and categories work as intended
• with no tags, pagination and categories enabled, pelican throws an error : CRITICAL: File /var/www/blog/htdocs/caaaaategory/index.html is to be overwritten
• with no category, pagination and tags enabled, pelican throws an error : CRITICAL: File /var/www/blog/htdocs/taaaag/index.html is to be overwritten
• with everything enabled, pelican throws an error : CRITICAL: File /var/www/blog/htdocs/taaaag/index.html is to be overwritten
• with everything enabled but no PAGINATION_PATTERNS set, it's ok

So this is similar to what @dandydev already said.

Pelican debug log

Click here.

pelicanconf.py

#!/usr/bin/env python
# -*- coding: utf-8 -*- #
from __future__ import unicode_literals

AUTHOR = u'test'
SITENAME = u'test'
SITEURL = ''
PATH = 'content'
TIMEZONE = 'Europe/Paris'
DEFAULT_LANG = u'en'
DELETE_OUTPUT_DIRECTORY = True
OUTPUT_PATH = '/var/www/blog/htdocs/'
THEME = 'notmyidea'
FEED_ALL_ATOM = None
CATEGORY_FEED_ATOM = None
TRANSLATION_FEED_ATOM = None

CATEGORY_URL = 'caaaaategory/{slug}'
CATEGORY_SAVE_AS = 'caaaaategory/{slug}.html'

TAG_URL = 'taaaag/{slug}'
TAG_SAVE_AS = 'taaaag/{slug}.html'
TAGS_URL = 'taaaags'
TAGS_SAVE_AS = 'taaaags.html'

DEFAULT_PAGINATION = 3
PAGINATION_PATTERNS = (
    (1, '{base_name}/', '{base_name}/index.html'),
    (2, '{base_name}/page/{number}', '{base_name}/page/{number}.html'),
)

setup:

-Python 2.7.6
-Markdown 2.4.1
-Pelican 3.3.1.dev
-Ubuntu 14.04 LTS

[Scheirle]

@barraudf I can't reproduce your error, but that's probably because I have different tags, categories and test articles.

But in your pelicanconf.py are quite some errors:

For Example you tag-url: TAG_URL = 'taaaag/{slug}' will become taaaag/t1 for a tag t1 but there is no such file there only is a taaaag/t1.html file (TAG_SAVE_AS = 'taaaag/{slug}.html)

So either you use:

TAG_URL = 'taaaag/{slug}/'               #Generates: taaaag/t1/
TAG_SAVE_AS = 'taaaag/{slug}/index.html' #Generates: taaaag/t1/index.html

(which works because http servers automatically send the index.html file if a folder is requested.)

or

TAG_URL = 'taaaag/{slug}.html'     #Generates: taaaag/t1.html
TAG_SAVE_AS = 'taaaag/{slug}.html' #Generates: taaaag/t1.html

You have the same error for CATEGORY and your PAGINATION_PATTERNS.

If this also doesn't help please let us know how your site is set up exactly (tags, categories, ...).

[barraudf]

Oh sorry, this works with my setup because i configured nginx accordingly:

location /
{
        try_files $uri $uri.html $uri/index.html =404;
}

I did this to avoid loads of directories only filled with a single index.html file.

But giving a try to default values for CATEGORY_*, TAGS_* and TAG_* give the same critical error message.

I used cat1, cat2 as category and tag1, tag2, tag3 as tags.

[Rogdham]

Many thanks to @dandydev, @barraudf for the all the details added to this bug report. I finally managed to reproduce the bug, and after diving into the details, it seems that the solution is quite easy: use {name} and not {base_name} in the PAGINATION_PATTERNS setting.

I believe this is an error in the doc, see the PR #1367 I just made.

Edit: will not work, see comment below.

---

@Scheirle wrote:

But in your pelicanconf.py are quite some errors:
[…]

Some http servers automatically add the extension as well, so I think this is the rationale for @barraudf's conf.

Edit: seems like @barraudf was faster than me at replying.

[Rogdham]

My bad, the fix mentioned above does not work: it results in the list of articles being in /index/index.html, /index/page/2/index.html, etc. Which is not what we want.

---

Here is the problem (using PAGINATION_PATTERNS as in the doc):

• for the list of articles, we want /index.html, /page/2/index.html instead of just /index.html
• for the list of tags, we want /tags/tagname/index.html, /tags/tagname/page/2/index.html instead of just /tags/tagname.html
  (same for categories…)

So the question is : how to know from /index.html or /tags/tagname.html if we should keep the right-part-but-the-extension (index or tagname)?

Does it makes sense to “split” the PAGINATION_PATTERNS: adding a PAGINATION_TAG_PATTERNS and so on?

[barraudf]

Don't forget Categories, same issue i guess

[Scheirle]

Ok, @Rogdham and @barraudf you are trying to do two different things (according to your description and config files):

@Rogdham wants clean urls and all files are named index.html, therefore the config should look like this:

CATEGORY_URL            = 'category/{slug}/'
CATEGORY_SAVE_AS        = 'category/{slug}/index.html'

TAG_URL                 = 'tag/{slug}/'
TAG_SAVE_AS             = 'tag/{slug}/index.html'

PAGINATION_PATTERNS     = (
    (1, '{base_name}/',               '{base_name}/index.html'),
    (2, '{base_name}/page/{number}/', '{base_name}/page/{number}/index.html'),
)

This works fine for me, as you can see here: http://blog.scheirle.de/testing/en/tag/pelican/page/2/

---

@barraudf instead wants that the files have the name of the slug, so the config looks like this (I added the .html extension to make it clear):

CATEGORY_URL     = 'category/{slug}.html'
CATEGORY_SAVE_AS = 'category/{slug}.html'

TAG_URL          = 'tag/{slug}.html'
TAG_SAVE_AS      = 'tag/{slug}.html'

PAGINATION_PATTERNS = (
    (1, '{base_name}/',                   '{base_name}/index.html'),
    (2, '{base_name}/page/{number}.html', '{base_name}/page/{number}.html'),
)

This also does not work for me. I assume the reason for this is, that via the TAG_SAVE_AS setting you assume that the tag (e.g.: t1) generates a t1.html file in the tag folder. But via the PAGINATION_PATTERNS on Page 1 you overwrite the TAG_URL with tag/ and TAG_SAVE_AS with tag/index.html. And now the error that the index.html is overwrite makes sense (since every tag now has the same url and path).

In addition: for pages 2 and above all the different tags would share one page folder, which would then again lead to an overwrite of the {number}.html files.

[barraudf]

@Scheirle : Even when I try setting PAGINATION_PATTERNS as shown in the doc, using CATEGORY_URL, CATEGORY_SAVE_AS, TAG_URL and TAG_SAVE_AS default values, I keep getting an error message from pelican (file to be overwritten).

Here is the exact pelicanconf.py used:

#!/usr/bin/env python
# -*- coding: utf-8 -*- #
from __future__ import unicode_literals

AUTHOR = u'test'
SITENAME = u'test'
SITEURL = ''
PATH = 'content'
TIMEZONE = 'Europe/Paris'
DEFAULT_LANG = u'en'
DELETE_OUTPUT_DIRECTORY = True
OUTPUT_PATH = '/var/www/blog/htdocs/'
THEME = 'notmyidea'
FEED_ALL_ATOM = None
CATEGORY_FEED_ATOM = None
TRANSLATION_FEED_ATOM = None

DEFAULT_PAGINATION = 3
PAGINATION_PATTERNS     = (
    (1, '{base_name}/',               '{base_name}/index.html'),
    (2, '{base_name}/page/{number}/', '{base_name}/page/{number}/index.html'),
)

And a sample 00.md (there are 14 files like this one, with incremental numbers, only 00 and 01 have tags and category):

title: 00
date: 2014-02-10
category: cat1
tags: tag1, tag2

00
==

00

This produces the same debug output as the one I linked earlier.

[Scheirle]

@barraudf That's because the defaults are:

CATEGORY_URL     = 'category/{slug}.html'
CATEGORY_SAVE_AS = 'category/{slug}.html'

TAG_URL          = 'tag/{slug}.html'
TAG_SAVE_AS      = 'tag/{slug}.html'

And then the same error as I described above occurs.

[barraudf]

I'm sorry, but with

DEFAULT_PAGINATION = 3
CATEGORY_URL            = 'category/{slug}/'
CATEGORY_SAVE_AS        = 'category/{slug}/index.html'

TAG_URL                 = 'tag/{slug}/'
TAG_SAVE_AS             = 'tag/{slug}/index.html'

PAGINATION_PATTERNS     = (
    (1, '{base_name}/',               '{base_name}/index.html'),
    (2, '{base_name}/page/{number}/', '{base_name}/page/{number}/index.html'),
)

I still get the error. Could an external setting (python or whatever) be involved?

[Scheirle]

I still get the error. Could an external setting (python or whatever) be involved?

Did you deleted the cache folder after changing your config?

[barraudf]

Soooo, there is a cache folder!

Deleting it solved the problem on the fresh quickstart site.

I still have some work to do with my real site to make the theme, subcategory plugin and config file work together, but I guess i'll manage to figure them out, thanks to all these explanations.

[smartass101]

Caching is giving you issues, eh? By default only the content and metadata as returned by readers is cached, so I'm not sure how it could have interfered. @Scheirle, why do you think deleting the cache folder helped? Python does its own byte-compile caching in *.pyc or __pycache__ too btw, could that be it?

[barraudf]

I got everything working.

The subcategory plugin has to be configured the same way that categories and tags. The settings included in the doc don't work :

'SUBCATEGORY_SAVE_AS' = os.path.join('subcategory', '{savepath}.html')
'SUBCATEGORY_URL' = 'subcategory/(fullurl).html'

Has to be :

'SUBCATEGORY_SAVE_AS' = os.path.join('subcategory', '{savepath}/index.html')
'SUBCATEGORY_URL' = 'subcategory/(fullurl)'

Theme needs a little work too if you want pagination like that :

prev | 1| 2 | 3| next

Because some parts of urls are kind of hardcoded into the template.

[justinmayer]

What's the consensus here? Is there any actions that should be taken with regards to this issue?

[barraudf]

If you get the warning saying a file is to be overwritten, you may have a config variable (*_SAVE_AS) incorrectly set

[DonDebonair]

Sorry, I still don't get it. I might me stupid or something, but I still get the following error message: CRITICAL: File /Users/daan/projects/dandydev.net/output/tags/index.html is to be overwritten
Here's the relevant settings:

TAG_URL = 'tags/{slug}.html'
TAG_SAVE_AS = 'tags/{slug}.html'
TAGS_URL = 'tags.html'
PAGINATION_PATTERNS = (
    (1, '{base_name}/', '{base_name}/index.html'),
    (2, '{base_name}/page/{number}/', '{base_name}/page/{number}/index.html'),
)

The only way I could see this go wrong, is if I actually have a tag named index, because then TAG_SAVE_AS and the PAGINATION_PATTERNS for tags would conflict. But this is simply not the case. Can anyone point me to what I'm doing wrong here?

[Scheirle]

@dandydev please re read #1223 (comment) (Your TAG_* settings are wrong)

TAG_URL                 = 'tag/{slug}/'
TAG_SAVE_AS             = 'tag/{slug}/index.html'

@justinmayer As far as I can tell, all comments since 9 Feb ( #1223 (comment) ) are not related to the original issue. They only revolves around how to set *_URL and *_SAVE_AS correctly to work with pagination.

[DonDebonair]

@Scheirle I've read that comment. My TAG_* settings are not wrong. Why shouldn't I be able to save tag pages as {slug}.html. The whole idea of those settings is that I can customize them, right? As I stated in my previous comment, I can't see how my tag settings would conflict with pagination.
I don't want to use TAG_SAVE_AS = 'tag/{slug}/index.html', because then I get lots of dirs with only an index.html in them.

Regardless if this has to do with the original issue, I'm seeing buggy behaviour and I really would like to see that sorted out.

[Rogdham]

@dandydev: could you try the following?

for TAG_:

TAG_URL = 'tags/{slug}.html'
TAG_SAVE_AS = 'tags/{slug}.html'

And use {name} instead of {base_name} for PAGINATION_PATTERNS, for example:

PAGINATION_PATTERNS = (
    (1, '{name}.html', '{name}.html'),
    (2, '{name}/page/{number}.html', '{name}/page/{number}.html'),
)

This gives me the following structure: (with tags abc and def):

output
├── tags
│   ├── abc
│   │   └── page
│   │       └── 2.html
│   ├── abc.html
│   ├── def
│   │   └── page
│   │       └── 2.html
│   └── def.html

---

@justinmayer: I believe this whole issue is either a problem in the documentation or in the way the impacted settings are defined. The problem is in the interactions of the PAGINATION_PATTERNS and TAG_SAVE_AS (same for categories), more precisely how the value from TAG_SAVE_AS is picked up and transformed according to PAGINATION_PATTERNS.

I think there are two ways to solve this issue:

• Improve the documentation (give more examples, explain the difference between {name} and {base_name} in PAGINATION_PATTERNS, etc);
• Change the way the pagination interacts with the TAG_SAVE_AS (same for categories), maybe define a PAGINATION_TAG_PATTERN or something like that.

Finally, I believe that this quite an important issue. Because of the no-override feature, if there is a file clash, the whole blog generation breaks. I still believe that this is a good thing, for two reasons:

1. This only happens when we configure the blog initially (×) (i.e. this is a one time problem: once the setting file is set up, it's all good –one could argue that we may lose future users because of that);
2. This forces the user to correct the problem, which would go unnoticed otherwise (e.g. all different tag pages collapsing into one).

(×): not exactly true: it will happen for example once two different tags are set, which may not be the case at the first blog post.

Just my two cents.

[DonDebonair]

@Rogdham I tried your settings with the following results:

• Good news: no override errors anymore
• Not ideal: now it generates directories for each tag:
  • tags/programming/index.html
  • tags/python/index.html
  • tags/datascience/index.html
  • ...
• Bad news: the homepage (index) is also put in a dir:
  -index/index.html
  • index/page/1/index.html
  • ...

I think the homepage (index) should be a special case. We want the index.html for the first page to end up in the root, and below that a page dir with (depending on PAGINATION_PATTERNS) number-dirs containing index.html's or {number}.html's.

As it stands now, PAGINATION_PATTERNS has probably been implemented too naievely.

[Rogdham]

@dandydev: you are sure about that?

For reference, I just made a fresh Pelican blog from pelican-quickstart, here is my full configuration file:

#!/usr/bin/env python
# -*- coding: utf-8 -*- #
from __future__ import unicode_literals
AUTHOR = u'me'
SITENAME = u'Title'
SITEURL = ''
PATH = 'content'
TIMEZONE = 'Europe/Paris'
DEFAULT_LANG = u'en'
FEED_ALL_ATOM = None
CATEGORY_FEED_ATOM = None
TRANSLATION_FEED_ATOM = None
DEFAULT_PAGINATION = 2
TAG_URL = 'tags/{slug}.html'
TAG_SAVE_AS = 'tags/{slug}.html'
PAGINATION_PATTERNS = (
    (1, '{name}.html', '{name}.html'),
    (2, '{name}/page/{number}.html', '{name}/page/{number}.html'),
)

And added posts that are like the following (same as in a previous message):

title: 00
date: 2014-02-10
category: cat1
tags: tag1, tag2

00
==

00

After a make html, here is the listing of all the files I have:

.
├── cache
│   ├── ArticlesGenerator-Readers
│   └── PagesGenerator-Readers
├── content
│   ├── 01.md
│   ├── 02.md
│   ├── 03.md
│   └── 04.md
├── develop_server.sh
├── fabfile.py
├── Makefile
├── output
│   ├── 00.html
│   ├── 02.html
│   ├── 03.html
│   ├── 04.html
│   ├── archives.html
│   ├── author
│   │   ├── me
│   │   │   └── page
│   │   │       └── 2.html
│   │   └── me.html
│   ├── authors.html
│   ├── categories.html
│   ├── category
│   │   ├── cat1
│   │   │   └── page
│   │   │       └── 2.html
│   │   └── cat1.html
│   ├── feeds
│   │   ├── me.atom.xml
│   │   └── me.rss.xml
│   ├── index
│   │   └── page
│   │       └── 2.html
│   ├── index.html
│   ├── tags
│   │   ├── tag1
│   │   │   └── page
│   │   │       └── 2.html
│   │   ├── tag1.html
│   │   ├── tag2
│   │   │   └── page
│   │   │       └── 2.html
│   │   └── tag2.html
│   ├── tags.html
│   └── theme
│       ├── css
│       │   ├── main.css
│       │   ├── pygment.css
│       │   ├── reset.css
│       │   ├── typogrify.css
│       │   └── wide.css
│       └── images
│           └── icons
│               ├── aboutme.png
│               ├── bitbucket.png
│               ├── delicious.png
│               ├── facebook.png
│               ├── github.png
│               ├── gitorious.png
│               ├── gittip.png
│               ├── google-groups.png
│               ├── google-plus.png
│               ├── hackernews.png
│               ├── lastfm.png
│               ├── linkedin.png
│               ├── reddit.png
│               ├── rss.png
│               ├── slideshare.png
│               ├── speakerdeck.png
│               ├── stackoverflow.png
│               ├── twitter.png
│               ├── vimeo.png
│               └── youtube.png
├── pelicanconf.py
├── pelicanconf.pyc
└── publishconf.py

As you can see, there is no extra index.html file for the tags or categories, and the root index is directly in output. Everything seems to be ok, and I've tested that the generated links are working as expected, and they are.

I hope gave you enough details for you to be able to reproduce (btw, I used the last master of Pelican a3c8fca). It seems to work great on my end, so it would be quite frustrating if it does not on your side.

[DonDebonair]

Hi @Rogdham

I tried to fiddle some more with the PAGINATION_PATTERNS on my own blog. The settings you proposed are different than what I had before. The following settings (the ones you suggested) work fine:

PAGINATION_PATTERNS = (
    (1, '{name}.html', '{name}.html'),
    (2, '{name}/page/{number}.html', '{name}/page/{number}.html'),
)

Now I'm left with only one problem, and that is of the index page. The above PAGINATION_PATTERNS are in my pelicanconf.py, but for my publishconf.py I have the following:

PAGINATION_PATTERNS = (
    (1, '{name}', '{name}.html'),
    (2, '{name}/page/{number}', '{name}/page/{number}.html'),
)

NGinX is configured in such a way that it tries to serve the .html version of any URL it can't resolve. That allows me to have clean looking urls. The above settings work on my server, except for the fact that for pages 2..n of my index/homepage, the url becomes: http://mysite.net/index/page/2. Then if I click on 1 to go back to the first page, it resolves to http://mysite.net/index. Now it displays the index page correctly, but the /index path is ugly IMHO. (note: the index page will be displayed both on / and /index with these settings)
That's why I said in my previous comment that the index page(s) of a site should be handled as a special case. Is there way to fix this?

Also, what's the difference between name and base_name?

[DonDebonair]

Also, when you use the settings from the documentation (substituting base_name with name, the homepage/index page (page 1) will be served at /index/. So not on / (which worked with my publish settings in the above comment). It isn't supposed to work like that right?

[DonDebonair]

Any reaction to my latest comments? :) Pardon my french, but it seems that the PAGINATION_PATTERNS is still a mess. The feature is a lovely idea, but really doesn't work as it should yet. I really invite any contributers to clone my site and my theme and try out the PAGINATION_PATTERNS. I think it's a more useful "real world" usecase than artificially created test blogs :)

[luzfcb]

Hello, i have a same issue to build the pull-request pythonclub/pythonclub.github.io#188 of pythonclub/pythonclub.github.io

which is the correct way to fix this issue?

It's very strange, the error only happens when I use the tag python3
remove the tag python3 of all articles does not seem reasonable.

See full traceback: https://gist.github.com/luzfcb/42a2eb6c5d292c661d67

[jonnyplatt]

Hello,

I'm having RunTimeError: File (...) is to be overwritten errors unrelated to the pagination issue, but I disagree that it should be a critical error halting the blog production process.

My case is quite simple: pages or articles with duplicate titles and default {slug} settings.
This isn't an unusual situation, but our users can't understand why their blogs no longer generate when there is a duplicate title in the system.
If you look at other CMS' handling of duplicate permalinks they tend to fix it by appending a number eg: {slug}-0 , {slug}-1 etc - wouldn't it be better if Pelican did something similar instead of terminating the build entirely?

[ingwinlu]

configure pelican to not use the title alone as the slug

or even better, configure your urls so they can not overlap

[llazzaro]

I got the same error.
I fixed it by using {name} instead of {base_name} for PAGINATION_PATTERNS.

[justinmayer]

This issue has been around for a while, and I think the general consensus is that it is up to users to ensure that files aren't overwritten. The previous behavior silently overwrote files, so the current behavior is at least an improvement over that. If someone wants to propose a specific improvement to the current behavior, and said person is willing to implement a solution along with docs and tests if the proposal is approved, then please feel free to submit a proposal in a new issue.