Forum Replies Created
-
Replies
-
Hola Aldo.
Siento que nadie haya respondido a tu mensaje, pero si lo he leído con atención no lo he entendido. ¿Tienes algún problema con Xampp o Wampp? ¿Qué relación tiene Chrome con esto?
Si tu problema es la configuración de tu servidor local, te sugiero que vayas al foro de desarrolladores de servidores:https://community.apachefriends.org/f/ABCD, como WordPress y otros, es sólo una aplicación que se ejecuta en el servidor y puede funcionar en otros tipos de servidores, pero es necesario estar familiarizado con este tipo de servicio.
Hi, Renate.
It took me a while to answer because I needed to test on a base what you reported.
I don’t know if I went in the same place as you, but using Export by Text and putting “R” in the “Repeat separator” field worked for me.
In my test I put 2 values in a field:
Example:
^a123456789
^a987654312On export it came out:
^a123456789; ^a987654312The semicolon can easily be replaced, but ABCD managed to export the repetition.
Hello, Renate.
The configuration files for a database in Opac are located in the database itself in a directory called opac. See MARC database.
As reported in this Readme (https://github.com/ABCD-DEVCOM/ABCD2/blob/master/www/htdocs/opac/readme.md) The directory OPAC_CONF stores the files of common use the Opac and not more its databases.
To configure it from ABCD, go to ABCD Settings -> OPAC
Best regards,
Roger
Egbert,
I received the files of this database in trial mode and was able to analyse them more calmly.
I converted the database to text to try with Sublime Text and VSCode to locate the correct encoding, but what I could see is that it is practically irreversible.
To fix it the best chance is to convert the database to text and use “Replace” to batch correct the errors:
./i2id database > new_database.txt
This link explains a possible cause: https://php-de.github.io/jumpto/utf-8/
This site (https://dencode.com/) tries to find the correct encoding for text, I tried to play some database snippets and no satisfactory result.
My hypothesis is that this database was converted to UTF8 and used as ISO8859-1, because according to what I read in a forum the error happens when the file is with one encoding but is displayed as another, causing a mix up.
If there is a purer version of this database could help, but right now I only see the replacement as a resolution.
There are even tables for this, but it is a lot of work:
É -> É â€œ -> " †-> " Ç -> Ç Ãƒ -> à é, 'é à -> À ú -> ú • -> - Ø -> Ø Ãµ -> õ à -> í â -> â ã -> ã ê -> ê á -> á é -> é ó -> ó â€" -> - ç -> ç ª -> ª º -> º à -> à
Fixed: https://github.com/ABCD-DEVCOM/ABCD2/pull/472
Fix erros: PHP Deprecated: trim(): Passing null to parameter
The error “PHP Deprecated: trim(): Passing null to parameter” appears in newer versions of PHP.To correct it, where it says:
trim($tl)has changed to:
trim((string)$tl)Updates compatibility for PHP versions higher than 8xx
The error below is caused in PHP 8xx versionsFatal error: Uncaught TypeError: Unsupported operand types: string * int in /ABCD2/www/htdocs/central/dataentry/fmt.php:1120 Stack trace: #0 {main} thrown in /ABCD2/www/htdocs/central/dataentry/fmt.php on line 1120
To correct it was changed where it says:
$tag=trim(substr($linea,0,4))*1;
To:
$tag=(int)trim(substr($linea,0,4))*(int)1;
Hi Renate.
The error “Call to undefined function ldap_connect()” happens because the ldap extension has not been enabled in the php.ini file.
To fix this, I put a check in the file start.php that verifies if the variable $use_ldap is with the value 1=enabled. – The fix was sent in this PR: https://github.com/ABCD-DEVCOM/ABCD2/pull/470
If you keep getting ldap errors after updating, revise your config.php file to look like this:
$use_ldap=0;
Hi, Renate.
The file that has the Undelete command is fmt.php, only one line was added.
The other files had little visual changes, I think it will not cause problems in your ABCD if you keep the most updated versions
What I do not understand is why it is not working now. I reviewed the PR https://github.com/ABCD-DEVCOM/ABCD2/pull/465 and could not find the reason for the error.
I need more information.
Dear Peter,
Forgive me for asking so many questions, but due to distance and the static dynamics of the forum one has to check several points to locate the cause of this error.
Based on your last message, I remembered that there have been errors in the dictionary caused by the data itself. Characters like apostrophe, double quotes, single quotes in the middle of data end up breaking scripts.
So let’s go to the questions:
– Does this error occur in only 1 field?
– The amount of clicks that causes the error is always the same?
– Did you notice if the freezing happens from a specific point?As I said, I could not reproduce the error, which leads me to believe that the problem is in the data.
I await your confirmations.
Best regards.
Hola, Jesús.
Tu punto de vista es bastante parecido al mío. Yo también viví esa época en la que los bibliotecarios usaban Winisis, por ejemplo, con los ojos cerrados.
Cuando llegó ABCD exigiendo conocimientos de Apache, PHP, HTML, JavaScript…. más por supuesto el proceso de poner el sistema en Internet ahuyentó a los bibliotecarios.
A pesar de los lenguajes mencionados, ABCD es CDS/ISIS y esto lo hace extraño para los profesionales de la informática acostumbrados a los servidores de bases de datos relacionales.
Creo que después del trauma de los antiguos bibliotecarios, es hora de animar a los nuevos bibliotecarios a utilizar el sistema para desarrollar la autonomía de sus sistemas. Koha es una buena opción, pero como gestor de bases de datos para fondos ABCD es imbatible.