liturgical-calendar / liturgicalcalendarapi Goto Github PK

Seeing the contents requested will not change often, we should add cache-control headers to the JSON resources output by the API. This would probably avoid having to check against IP addresses in an attempt to avoid abusive usage of the API. If the JSON resources are generally cached, with an expiration of say 1 month, this should prevent the server from being bombarded by requests from a same IP or domain.

example:

header('Cache-Control: must-revalidate, max-age=259200'); //revalidate after one month

Thanks for this wonderful job. I am moving my application Liturgia+ to offline mode and would like to include a precalculated annual calendar taken from your API. But since the application incorporates the Liturgy of the Hours, I want to know if you plan to include the week of the psalter for each day.

One of the most delicate points for an application to work with a perpetual calendar is the part of the liturgy of the hours, especially the rules to decide the psalms, antiphons, office readings in two cycles (biennial) etc. Do you have something projected on this?

Most decrees that are issued, will change the state of the Universal calendar only until a new edition of the Missal is issued. We no longer need to apply them after the new Missal is published, since they will be incorporated into the Missal, and the Missal becomes the new source of truth.

For now, the patron saints of Europe are hardcoded in Italian, and work only with the Italian calendar.

The logic and any strings involved will need to be abstracted in such a way as to work with the proper locale for country in Europe.

The name of the festivity is getting updated correctly.
However the grade is not getting upgraded.

Why could that be?

I was testing with this query:

https://litcal.johnromanodorazio.com/api/dev/LitCalEngine.php?year=2001&nationalpreset=ITALY

None of the patrons have been updated to LitGrade::FEAST = 4, why is that?

Now that the bootstrap theme has been applied to the front page, it needs to be localized into a few different languages.
For starters I usually target Spanish, Italian, French, German and Portuguese.

So the question is, how do you handle localization in Bootstrap themes? And how can we go about doing so? Client side, with JSON and Javascript / jQuery? Server side in PHP?

Would probably also need to add a dropdown list with languages to choose from.

as was done with the BibleGet endpoint, it would be useful, other than the description provided in the README.md in the repo, to describe the API in Open API / Swagger / Postman format. WIP!

Now that we have started defining JSON schemas, and we have a number of schemas to work against, we have tried to distinguish within the schemas between properties that directly contribute to creating a Festivity object, and properties that contain supplementary information and which therefore can be placed in a Metadata object, alongside the Festivity object.

The DiocesanCalendar JSON schema needs to be brought up to par. The following properties should be moved from the Festivity object to a Metadata object:

1. formRowNum
2. sinceYear , also needs to be defined as integer, not as string with integer format!
3. decreeURL
4. decreeLangs

For now, do just the Liturgy of the Day as a news briefing, in Italian and in English, for different US timezones and for the Diocese of Rome liturgical calendar.

When the LitCal project was first started, we were using MySQL tables. These didn't have an actual "array" type, but MySQL has ENUMs and SETs, which are then translated to a comma-separated string. For this reason, LitColor and LitCommon were treated as strings pretty much everywhere.

Now that we have moved to JSON files, this representation can natively maintain arrays. So it is more natural for LitColor and LitCommon to be treated as arrays. This means adapting all enums and code using them to treat them as arrays... This is a move that must be made, because it has already been started. If it is not finished, it will currently trip up the engine.

Describe the bug
When attempting to retrieve a calendar from the API using a national preset paramenter, an error is returned. Making the request without the national preset parameter does not return the error.

To Reproduce
Enter in browser: https://johnromanodorazio.com/LiturgicalCalendar/LitCalEngine.php?year=2021&returntype=JSON&nationalpreset=USA
Following Error is returned:
Fatal error: Uncaught Error: Typed property Festivity::$liturgicalyear must not be accessed before initialization in /var/www/vhosts/johnromanodorazio.com/httpdocs/LiturgicalCalendar/Festivity.php:70 Stack trace: #0 [internal function]: Festivity->jsonSerialize() #1 /var/www/vhosts/johnromanodorazio.com/httpdocs/LiturgicalCalendar/LitCalEngine.php(2984): json_encode() #2 /var/www/vhosts/johnromanodorazio.com/httpdocs/LiturgicalCalendar/LitCalEngine.php(2951): GenerateResponseToRequest() #3 {main} thrown in /var/www/vhosts/johnromanodorazio.com/httpdocs/LiturgicalCalendar/Festivity.php on line 70

Expected behavior
JSON calendar should be returned.

Screenshots

Desktop (please complete the following information):

• OS: Manjaro Linux
• Firefox 94.0.2

Currently, i18n is handled with PHP arrays. However, this is all done manually, and is not very sustainable moving forward. It's not very useful to load into memory a huge array with all the languages, just to retrieve one language.

It would be much better to use gettext, which is built into PHP. And po / mo files can be hooked into a translation server such as Weblate, in order to better handle translations.

Update the calendar data starting from 2022 based on the following Decree:

https://www.vatican.va/content/francesco/en/events/event.dir.html/content/vaticanevents/en/2022/1/21/decreto-santireneo.html

Now that the index.json file implementation has been created, already existing diocesan calendars can be checked against this index. However, directly requesting the index.json file in an ajax request will be limited by CORS policy. We need to be able to allow responses to be sent to authorized request origins, and the easiest way to do this is in PHP (rather than trying to set it up in the nginx / apache server directly).

This would mean that instead of trying to retrieve index.json directly, we should have a metadata endpoint in PHP that will return the index.json resource if the Origin of the request is among the allowed / whitelisted origins. This will also prevent problems stemming from requests that might originate on both a www and non-www domain, as long as both are included in the allowed origins.

Saint Vincent deacon is an optional memorial. In any case in the national calendar for USA, it is moved from Jan 22 to Jan 23, in order to make room for the national day of prayer for the unborn.

But for some reason, at least in the year 2022, Saint Vincent deacon is getting a Vigil Mass! It falls on a Sunday (Jan 23), which has its own Vigil Mass!

Better look into how Saint Vincent is being moved, and how Vigil Masses are being created...

1. Not present in Missale Romanum 1962
2. Present in Missale Romanum 2002
3. Present in Italian Missal 1983
4. Was the memorial present in the Missale Romanum 1975? 1970? 1971?

For better portability of the data, and to better allow plugging in to Translation services such as Weblate which would allow for better community participation, and an overall better experience in handling and translating the calendar data,

I started to move away from MySQL tables, towards JSON data sources. This required rewriting quite a bit of the logic of how the data is imported and handled within the API. It was also the opportunity to create the FestivityCollection class which allows for further optimizations, helping clean up the LitCalAPI class which has really been overloaded.

Commits that have gone towards this are:

• fd40730 finalize JSON data sources
• f3236d1 create FestivityCollection class
• 38a6b42 remove outdated array
• 7e4169b optimize litevent creation for decrees
• f5e0e91 create method to handle updates to a litevent's grade property
• 0876146 create method to optimize moving litevents for USA calendar

However there is still MySQL data being used when creating national calendars. The JSON data sources have been put into place, now we just need to write the logic to handle these data sources instead of continuing to rely on MySQL...

The applyMemorialsBasedOnDecreeX methods are manually defining translation strings for English, Italian and Latin.

Instead, this data should be pulled in from an external JSON data file, with supporting json translation files, to allow for any language.

This would also allow to combine a number of methods that are doing pretty much the same thing:

Reading some of the discussions on this stackoverflow post, it seems that according to the Open API specification, DATE-TIME types are expected to be represented according to RFC3339.

Reading up on RFC3339, I see that DATE-TIME should be represented as YYYY-MM-DDTHH:MM:SSZ where T delimits the date string from the time string and Z indicates UTC time.
The same ref spec also says that for readability, a space can be used instead of a T between date and time, which is what we are currently using in our representation in the case of the Metadata property with the FEASTS_MEMORIALS and the SOLEMNITIES arrays. DateTime objects in PHP are serialized by PHP's json_encode function. If we need them in a slightly different format, we would need to create our own DateTime class extending PHP's DateTime class, and implement a customized JsonSerializable, example here.

Now that liturgical calendar data is being moved to JSON files, we should define schemas that represent these JSON files. This will help create consistency in the schemas used, in order to avoid errors in the API engine when reading the files, or in the Frontend application when creating and writing the files.

I looked around a bit, but didn't see an option for changing output content, not giving the vigil information on Saturdays, or preferring a Saint's proper memorial over an optional BVM on Saturdays, and only give the BVM if there's nothing else? (e.g. output the highest ranking or a preferred type each day?)

I was thinking about digging in and looking at implementing this, possibly, but wanted to know if this exists or was desired or was in the works already.

1. Calendar of Filocalo, Chronograph of 354, contains the Depositio Martyrum as well as the Depositio Episcoporum. It can well be considered the first Liturgical Calendar in history.

   • source: see documents folder in the repository

2. The Verona Sacramentary is the oldest known liturgical book. It is not a sacramentary in the strict sense, but rather a private collection of libelli missarum (missal booklets) containing only the prayers for certain Masses. It is sometimes called "Leonine" because it has been attributed to Pope Leo I († 461). The three quires containing the period 1 January – 14 April are lost. Thus, there is no information in the earliest Roman liturgical book concerning the Easter Vigil.

   • source: ???

3. The Gelasian Sacramentary is the second oldest western liturgical book that has survived (Paris, 750 AD).

   • source: https://github.com/Liturgical-Calendar/LiturgicalCalendarAPI/blob/ec56c6f3439ba5c7f1085887a95f9a509f2eba4a/literature/0354-0354,_Furius_Dionysius_Filocalus,_Kalendarium_Anno_CCCLIV_Conscriptum,_MLT.pdf

4. The first move to unify the Roman liturgy took place under Charlemagne:

   Among several distinct rites current in the West before the 8th century, the two most influential were the Roman rite used in Italy south of Lombardy and the Gallican in use in most of the rest of Western Europe, save Iberia and the British Isles. By 700 the influence of the Roman sacramentary had modified Gallican usage. This mixture of rites represented in the Gelasian Sacramentary was superseded when Charlemagne asked Pope Hadrian to provide an authentic Roman sacramentary for use throughout the empire. In 785-86, the pope sent the emperor the Sacramentarium Hadrianum, a version of the Gregorian Sacramentary for papal use, which was adapted for the Carolingian empire.

   • Sacramentarium Hadrianum (785): https://www.latinitas.it/grh/

5. The first printed Missale Romanum (Roman Missal), containing the Ordo Missalis secundum consuetudinem Curiae Romanae (Order of the Missal in accordance with the custom of the Roman Curia), was produced in Milan in 1474.

   Annotations in the hand of Cardinal Gugliemo Sirleto in a copy of the 1494 Venetian edition[4] show that it was used for drawing up the 1570 official edition of Pope Pius V. In substance, this 1494 text is identical with that of the 1474 Milanese edition.

   • source: https://archive.org/details/missaleromanumme01cath

6. Implementing the decision of the Council of Trent, Pope Pius V promulgated, in the Apostolic Constitution Quo primum of 14 July 1570, an edition of the Roman Missal that was to be in obligatory use throughout the Latin Church except where there was another liturgical rite that could be proven to have been in use for at least two centuries.

   • source: https://github.com/Liturgical-Calendar/LiturgicalCalendarAPI/blob/6c1185c1cfac59bef59601b4c0112b3968f75290/literature/1570-07-19,_SS_Pius_V,_Missale_Romanum,_LT.pdf

7. Some corrections to Pope Pius V's text proved necessary, and Pope Clement VIII replaced it with a new typical edition of the Roman Missal on 7 July 1604. (In this context, the word "typical" means that the text is the one to which all other printings must conform.)

   • source: http://books.google.it/books?id=u7xFAAAAcAAJ&printsec=frontcover&dq=Missale&hl=it&ei=qk5ATu6vEoup8APij73-Ag&sa=X&oi=book_result&ct=result&resnum=2&ved=0CDIQ6AEwAQ#v=onepage&q&f=false

8. A further revised typical edition was promulgated by Pope Urban VIII on 2 September 1634.

   • source: https://www.digitale-sammlungen.de/de/view/bsb10869696

Along the same lines as an Amazon Skill, let's try to create an interactive Google Assistant action with Liturgical facts!

Getting started information can be found here: https://codelabs.developers.google.com/codelabs/actions-builder-1/#0

For National Calendars, the settings for Epiphany, Ascension and CorpusChristi are still hardcoded for NationalCalendar values of VATICAN, ITALY, and USA.

These settings are already defined in the National Calendar JSON source data files. They should be automatically set based on the values defined in the JSON source file.

Contact Details

[email protected]

What happened?

The counting of the days before and after Epiphany seems to be wrong.

The days before Epiphany should be named “Feria VI temporis Nativitatis” for “Friday Christmas Weekday”.

The days after Epiphany should be named “Feria II post Epiphaniam” for “Monday Christmas Weekday”.

Sources for the Latin and English are the Ordo Missae Celebrandae et Divini Officii persolvendi and the Liturgical Calendar for the Dioceses of the United States of America.

As things stand, we seem to be following the rule stated in the Romcal Project:

If Epiphany is celebrated on Jan. 6:
2. Days from Jan. 2 through Jan. 5 are called "*day before Epiphany"
5. Days between Jan. 6 and the following Sunday are called "*day after Epiphany"

If Epiphany is not celebrated on Jan. 6 (i.e., celebrated on Sunday):
2. Days after Jan. 1 but before the Sunday occurring from Jan. 2 through Jan. 8 are called "*day before Epiphany"
5. If Epiphany occurs on or before Jan. 6, then the days of the week following Epiphany are called "*day after Epiphany"

I have noticed in a few situations that the rules for RomCal seem to follow the English liturgical calendar (in England), so I have had to correct a few of them to be in line with the Universal Calendar and most other national calendars. I will try looking into this a bit more, to see how exactly it is printed in the liturgical calendars for Italy and the United States, perhaps a correction may have to be made.

Version

v3 (Default)

Which browsers are you seeing the problem on?

No response

Relevant error messages

No response

How can $coincidingFestivity have an event property if it has only been initialized as a basic stdClass() object? How was it supposed to be initialized?

Issue #112 was taken care of by PRs #142 and #147 , and we now have full support for the different languages in a wider region.

However we may need to do further development for multiple languages within a single country.

For example in the United States, both English and Spanish are supported. So we should be able to define data for the United States both as "English USA" and "Spanish USA".

The liturgical calendar is calculated by year. The General Roman Calendar data has now been defined, and will not change until a new decree of the Congregation for Divine Worship will come out. Any decree that will come out will apply to future years, not past years. The same for national calendars: so far we have defined data for Italy and the United States. This data might need some small update for future years, but not for past years.

Since this data doesn't change (unless a typo is found), there really isn't any need to recalculate it each time the API receives a request. So responses will be much faster if the data is cached in a static manner by writing for example the JSON or XML files. Then the JSON result would be served immediately instead of calculating the data each time. Perhaps these JSON files could be recalculated when a change is made to the data (for example a typo is fixed), and this could be handles by versioning.

TODO: implement cacheing of calculated results in a static JSON file, which should be versioned based on the API version.

For festivities of doctors of the Church, sometimes we write "... and doctor", and sometimes we write "... and doctor of the Church". Check the English missal 2011 and use whatever is there for consistency.

I have been told that some dioceses may override the choices of the episcopal conference / Roman Missal when it comes to Ascension and Corpus Christi (and perhaps Epiphany). So we must allow a diocesan calendar to override the national calendar in these cases.

Perhaps we could have a default value of "inherit" for diocesan calendars, if it doesn't override the national calendar.

It would be nice to have a github action run on pushes to the dev branch, which will execute xgettext on the newly pushed code to update any possible changes to translation strings in the source code, and regenerate the pot file. This would avoid having to remember to do it manually from the command line. I haven't seen any similar Github actions, perhaps one will have to be created from scratch...

add the swaggerdocs themselves, and add a link on the presentation page to the swaggerdocs

the difference between the API script and the examples should be more evident in the central area of the page, as it is in the sidebar

Contact Details

No response

What happened?

During the canonization of St. Faustina Kowalska, Pope John Paul II instituted Divine Mercy Sunday: https://www.vatican.va/content/john-paul-ii/en/homilies/2000/documents/hf_jp-ii_hom_20000430_faustina.html

Version

dev (Edge)

Which browsers are you seeing the problem on?

No response

Relevant error messages

No response

Still getting an error:

Currently, in this draft of creating and handling Wider Region calendar data, we have accounted for a Wider Region having multiple languages. However, since the translation data for the wider region is finalized to a single country's Roman Missal, the translation will in fact need to be differentiated by country, not just by language.

For example, "Our Lady of Guadalupe" is patroness of the Americas. In the USA, the English translation will show "[ USA ] Our Lady of Guadalupe". However, this will not hold for Canada or other countries with an English Missal. Therefore the translations need to be further identified by geographic area / country.

Now that a simple Liturgy of the Day news brief has been created, look into a more interactive and informative skill!

as a start, I created the endpoint on my own domain. Getting a domain for each project has it's costs, so to keep costs down, especially during the initial development phase, I just created it on my personal domain. If it were to become a more useful project, it would be nice to find a better home... hopefully a diocese or (God willing!) the Vatican if it turns out to be a stable and useful project 😄 one step at a time, for the glory of God and his Church.

PHP Fatal error: Uncaught TypeError: LitMessages::ParseColorString(): Argument #1 ($string) must be of type string, array given, called in /var/www/vhosts/johnromanodorazio.com/httpdocs/LiturgicalCalendar/api/dev/includes/LitCalAPI.php on line 2348

Seeing that the Commons of the BVM / Saints are pretty much the same between different language Missals, I believe we should be able to create a class which will act as an ENUM on one hand, and will facilitate the translation of the names of the Commons with gettext on the other hand.

Currently the metadata API only lists defined Diocesan Calendars, and relative national calendars.

However, it should separately list national calendars that are supported by the main API, even if no diocesan calendars are defined. And applications should be able to receive and use this information, rather than manually adding such national calendars when no diocesan calendars are defined.

Whenever an attempt is made to generate ICS output, an error occurs.

There is no obvious error, but if the ICS file is examined, here is the output:

Regardless of the endpoint, I have tried many variations, as long as ICS is return type, the error occurs.

Desktop (please complete the following information):

• OS: macOS
• Browser safari and chrome

Currently, as proof of concept, I have integrated a Diocesan preset for the Diocese of Rome, which alters the data produced by the Universal Calendar and the Italian calendar approved by the CEI (Italian Episcopal Conference) and published in the Italian translations of the Roman Missal.

These calculations should be made separate from the main script, so as to allow modularization for any diocese in the world. If it is possible to calculate the calendar for the Diocese of Rome in a separate script, using the flux of data from the main script, then it should be possible for any other diocese. This needs to be studied carefully...

move "API endpoint" and "Easter calculation" out of the examples section on the side menu

Saturday memorials of the Blessed Virgin Mary

On Saturdays in Ordinary Time when there is no obligatory memorial, an optional memorial of the Blessed Virgin Mary is allowed.
Saturdays stand out among those days dedicated to the Virgin Mary. These are designated as memorials of the Blessed Virgin Mary. This memorial derives from Carolingian times (9th century), but the reasons for having chosen Saturday for its observance are unknown. While many explanations of this choice have been advanced, none is completely satisfactory from the point of view of the history of popular piety.
Whatever its historical origins may be, today the memorial rightly emphasizes certain values to which contemporary spirituality is more sensitive. It is a remembrance of the maternal example and discipleship of the Blessed Virgin Mary who, strengthened by faith and hope, on that “great Saturday” on which Our Lord lay in the tomb, was the only one of the disciples to hold vigil in expectation of the Lord’s resurrection. It is a prelude and introduction to the celebration of Sunday, the weekly memorial of the Resurrection of Christ. It is a sign that the Virgin Mary is continuously present and operative in the life of the Church.
Directory on Popular Piety and the Liturgy (2001), §188

Perhaps we should do even more and better sanitization of GET / POST requests. For example using the filter-input function.

• Move fixed date solemnities to calendar_fixed table to allow for localization
• Apply the same rules (coincidence with palm sunday and the likes) for all solemnities during the cycle from the mysql requests

Describe the bug
Before some of the recent optimizations, the coincidence of the Immaculate Heart with other memorials such as St. Irenaeus and St. Anthony (2014 and 2015 respectively) was handled correctly.

However, ever since the calculation of Memorials and Optional Memorials has been optimized into a single method calculateMemorials(), the coincidence of the Immaculate Heart with St. Irenaeus and St. Anthony in the years 2014 and 2015 is no longer being handled correctly.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://litcal.johnromanodorazio.com/api/dev/LitCalEngine.php?year=2014
2. Search for Immaculati Cordis
3. You will see the message that St. Irenaeus was suppressed: "The Memoria 'Sancti Irenæi, episcopi et martyris', added in the Editio Typica 1970 of the Roman Missal since the year 1970 () usually celebrated on 28 Iunius, is suppressed by the Memoria 'Immaculati Cordis Beatæ Mariæ Virginis' in the year 2014."

Expected behavior
The memorial of the ImmaculateHeart should be reduced to an optional memorial, and so should St. Irenaeus. Likewise with St. Anthony in 2015.

In 2012, Pope Benedict XVI gave faculty to the Episcopal Conferences, to insert the above mentioned Feast in their own liturgical calendars on the Thursday after Pentecost.

http://notitiae.ipsissima-verba.org/pdf/notitiae-2012-335-368.pdf

England was among the first to adhere: https://www.liturgyoffice.org.uk/Calendar/Sanctoral/OLJC-full.pdf

Italy simply maintained a votive Mass, without any particular date.