🇺🇸United States @AndrewGearhart

There isn't a feature that I know of built into bibcite that allows you to auto-fill the information from a page to generate a citation for the current page. While this would seem to be a neat feature, I don't think it's the focus of the Bibliography & Citation (bibcite) module. There was a D6/D7 "Cite" module, but it doesn't look like there's an equivalent of that in D8+. It looks like you would need a custom module to carry out what you're trying to accomplish.

AndrewGearhart → created an issue.

I'm running bibcite-3.0.0-beta4 and I'm unable to reproduce. I visited the page, clicked through each of the display types and saved each one without errors. ¯\_(ツ)_/¯

@paucala I would recommend, since you're needing to reparse the names anyway... (the additional step you mentioned to remove the ' y ') that you instead use a strange character boundary as your replacement foundation. 'y' would have a plausible place in a real name for example: "Thomas y Jesus Jimenez Corporation". Instead, if you were to have the names entered as "Pau Calabrés|Garcia" the parser would parse this as a first and last name, and you could run your reparsing of the names in the database to replace the '|' pipe character as a space.

I'm working on some pretty significant revisions for names in a module that I plan to release shortly (likely before the end of May 2024). I'd like to confirm how the name is entered, which is it:

1. Calabrés Garcia, Pau
2. Pau Calabrés Garcia
3. Pau Calabrés y Garcia
4. Calabrés y Garcia, Pau

My understanding is that you would like to enter it as #2, but you are planning to enter it as either #3 or #4.

One element that I'm considering for this is a bit more logic being entered into the name pattern whereby it would use some prioritization of the fields based upon number of entries and some anchoring of common entries. This isn't a problem that only exists with Spanish either. Some Scottish names too... but other name structures it doesn't do well with ... for instance:

• William Mc Gonnell
• Maria de la Cruz

If your dataset _isn't_ using middle names, the name parser could a pattern such as:
@prefix[#prefix_list] @first_name[1] @last_name[1-3]
(from the available tokens) - @prefix, @leading_title, @first_name, @middle_name, @last_name, @nick, @suffix
My theoretical breakdown of this would be that it would:

1. greedily search for a prefix that is in the prefix_list for a prefix
2. look for the next item to be a first_name
3. look for any other items 1-3 to include as a last name

I'm still working out, a) how to expand the parser to set optional items and how it should determine groupings beyond item count and order criteria (for instance, what should it do with a middle name if it was entered in my example parser... something like Maria Angelica de la Cruz. Should Angelica be discarded? This is one of the reasons that in my upcoming module, I am now storing the name as entered. When the parsing goes wrong, it is then something that could be used by an editor to determine how the name actually should be broken apart on the edit form. Ultimately, understanding that while the parser can get things better with this... it might not get _everything_ correct... and the name parts on the contributor edit screen are manually editable. Clearly, that is not a great solution though when you might be dealing with thousands of entries... but it's better than having indecipherable broken data!

Confirming RTBC

With bibcite on Drupal 10.2.3, php 8.2.8, got duplicate revision tab... applied these changes... worked like a charm.

@poker10 - I am able to produce a situation that is similar to the one that @solanas is identifying. After digging around, it seems that it is due to the separate removal and addition of the primary key. In my case, we're running a clustered innodb which requires primary keys on every table. In my case, I receive the following error:
SQLSTATE[42000]: Syntax error or access violation: 1235 This version of MySQL doesn't yet support 'existing primary key drop without adding a new primary key. In @@sql_generate_invisible_primary_key=ON mode table should have a primary key. Please add a new primary key to be able to drop existing primary key.'
This is because we've enabled the sql_generate_invisible_primary_key feature which is planned (to my understanding) to be set by default. When the primary key is removed in the patch, mysql gets angry (throws away your update) and advises that you should really add a new one, if you're going to remove a primary key. Which, @solanas' solution does.

Is there a reason that we're doing those steps separately? Can we not do that in the future? :)

In the meantime, I've put together the following that I'm doing to apply this update:
drush updb -y
drush sql-cli < /var/www/html/sites/default/files/tmp/session7086fix.sql
drush vset hash_session_ids TRUE

## session7086fix.sql
UPDATE `system` SET schema_version='7086' where filename = 'modules/system/system.module';
ALTER TABLE `sessions` DROP PRIMARY KEY, ADD PRIMARY KEY (`sid`,`ssid`);

Hope that helps others!