[Static]

Oops, I forgot to use [php][/p­­hp]. I'll try to remember in the future. To bad I can't edit my post to fix that now. Any Idea how to combine the two id values so that they work?

[Steven]

[Steven]

In fact, there should probably be a check to make sure that the custom Page ID does not match with any of the autoincrementing IDs. I suppose that could be done in the admin panel. The admin panel should check when you enter a custom Page ID that it is not an integer.

Edit: And also check that none of the custom Page IDs match each other.

[Static]

No, that doesn't work. Well, it does display it correctly, but commenting results in a ban for an incorrect referrer. What does the referrer have to do with it? Bans only for the custom id.
EDIT: This is for post #22

---

The check sort of complicated. If someone decides to edit a value in the database, then they could mess everything up. One id might be good enough, but I'll try something with two.

[Steven]

After thinking about it, how about this?

1. Add another (varchar) column called 'page_id'.
2. Make it a required field when creating a new page.
3. Change occurrences in the code from 'id' to 'page_id'.
4. Make sure the code can validate it properly.
5. During upgrade to v1.1, I think I can get the installer to rename the 'id' column to 'page_id' and add a new id column to replace it.

[Static]

[Steven]

Interesting. I'll take a closer look at this tomorrow.

It seems that you've also renamed the 'page_id' column in the subscribers table to 'custom_page_id'.

Also, why do you need two page id related columns in the comments table?

[Static]

Technically, you don't have to rename those columns, only change their type and value. I forgot about the subscribers column, but yes, you also have to rename that one, or create a new one with that name.

To answer your question, you don't. I left it in there just as a backup if I'll need it to be able to read both from the default id, and from the custom one.

[Steven]

When clicking on the 'RSS for this page' link, it would be good if the id in the URL uses the autoincrementing id column and not the custom page id. It seems a bit cleaner for it to use a number and not a string.

[Steven]

I think a better approach could be this:

Add another (varchar) column called 'custom_page_id' in pages table.
- This is an optional column.
- When you create a new page in admin, it's exactly the same as now.
- However when you edit a page, you can optionally enter a custom id.
- If entered, it checks to make sure it doesn't already exist.

The validate_page_id() function does the following:
- Checks whether the supplied page id exists in the 'custom_page_id' column. If it does then it validates and the script uses its corresponding id.
- If the supplied page id does not exist in the 'custom_page_id' column, check whether it exists in the id column. If it does then it validates and the script uses it.
- If it doesn't exist in either column then it doesn't validate.

As it would always use the id column (and never the custom id column) throughout the code, this means the following:
- The id parameter in the URL for the 'RSS for this page' link would use the integer id as normal and not the custom string.
- You could in theory edit your custom id in the admin panel at anytime without it messing anything up. Just remember to update your change in the page too.

The upgrade would be really simple. Upon upgrade v1.1 would continue to use the id column as normal.

Creating a new page would remain really simple. Only enter a custom id if you want to.

(This is obviously a big fundamental change so I think it's important to take some time with this to get it right.)