getgrav

getgrav

Modern, Crazy Fast, Ridiculously Easy and Amazingly Powerful Flat-File CMS

Member Since 7 years ago

Global

Experience Points
0
follower
Lessons Completed
0
follow
Best Reply Awards
134
repos
Activity
Jan
24
6 hours ago
Activity icon
fork

zccheng8320 forked getgrav/grav-plugin-admin

⚡ Grav Admin Plugin
zccheng8320 MIT License Updated
fork time in 36 seconds ago
Jan
23
1 day ago
started
started time in 12 hours ago
Activity icon
issue

bastian42 issue comment getgrav/grav-plugin-comments

bastian42
bastian42

Some comments are not saved

Hi,

I have a very mysterious bug with the “comment” plugin: some comments are not saved - about 1 of 10 comments are lost.

I use

  • Grav v1.7.25,
  • Quark v2.0.4 (slightly adapted - CSS and templates) as theme
  • Comments v1.2.8
  • Form v5.1.4 on PHP 8.1.0 (I also tested PHP 7.4.25 - same problem)

In the template I have integrated the comments as follows:

{% if config.plugins.comments.enabled%} {% include 'partials / comments.html.twig' with {'page': page}%} {% endif%}

The comment fields are also displayed correctly and 9 out of 10 comments are correctly saved and the email is also sent. Only about 1 in 10 comments simply go away (not saved and no mail).

I’ve already checked logs from Grav and Apache, but there is simply nothing to be seen.

There were no unusual signs in my tests. They were structured as follows: Test date // time // number Test 30.12.21 // 19:52 // #01

Then some of them are missing.

Does anyone have similar experiences or a tip on how I can fix the problem.

Thank you for your support!

bastian42
bastian42

@pamtbaau, I have done the following activities:

  • setup a fresh install of Grav using skeleton Blog Site
  • add plugin Comments
  • add {% include 'partials/comments.html.twig' with {'page': page} %} to /user/themes/quark/templates/item.html.twig
  • test

-> I have the same problem: some comments are lost!

-> I will give up with GRAV and comments... :-(

Jan
22
2 days ago
started
started time in 1 day ago
Activity icon
issue

ricardo118 issue getgrav/grav-plugin-admin

ricardo118
ricardo118

taskConvertUrls breaking nextgen editor for flex objects

Ive found out that this line:

https://github.com/getgrav/grav-plugin-admin/blob/develop/classes/plugin/AdminController.php#L3020

breaks the nextgen editor when trying to find out images to display. that exception triggers when using nextgen editor on a flex object (not a page), by commenting that line it seems to work fine so is the line necessary?

started
started time in 1 day ago
Jan
21
3 days ago
push

w00fz push getgrav/grav-plugin-admin

w00fz
w00fz

Oops, added changelog entry in wrong version

commit sha: eb3fdba942940cf0e7f42961068adb0c198ec388

push time in 2 days ago
push

w00fz push getgrav/grav-plugin-admin

w00fz
w00fz

Clean file names before displaying metadata modal

commit sha: 4e6e5c37b81a163d74edc5be2989c55b945e1e5a

push time in 2 days ago
push

w00fz push getgrav/grav-plugin-admin

w00fz
w00fz

Clean filename before presenting it to error modal

commit sha: d610d6ca4b3ca7995fd2fbae41b2754ee2746ef1

push time in 2 days ago
Activity icon
fork

Wesley-yang forked getgrav/grav

⚡ Modern, Crazy Fast, Ridiculously Easy and Amazingly Powerful Flat-File CMS powered by PHP, Markdown, Twig, and Symfony
Wesley-yang MIT License Updated
fork time in 2 days ago
Activity icon
issue

jonthurmond issue comment getgrav/grav-plugin-admin

jonthurmond
jonthurmond

After recent update, cannot edit Pages from Admin anymore - HTTP 500 Error

We recently did a step update from 1.7.12 (or .11) to 1.7.13 and updated the plugins.

However, now whenever we try to edit pages from the admin/pages (either by clicking on a page or right clicking ... and selecting the Edit option) we get a HTTP 500 error.

The website itself is working properly. It is just the admin editing of pages that seems broken. We were not having this issue before the update to 1.7.13.

jonthurmond
jonthurmond

The latest update does not help. Still getting Error 500 on a plain site with nothing but initial Grav installation. I know this could be on my hosting side, but they are no help and I am just not that good behind the scenes.

Activity icon
fork

hieuka2005 forked getgrav/grav-theme-afterburner2

⚡ Grav Afterburner2 Theme
hieuka2005 MIT License Updated
fork time in 2 days ago
Activity icon
issue

lufog issue comment getgrav/grav

lufog
lufog

Grav translation philosophy change

As I am using GRAV more and more and try to get more and more experience with it, I found, that translation model integrated into GRAV is not good. I am not talking about content but about GUI.

I am from Czech Republic and users there are very sensitive if the product is not available in local language - Czech language. Therefore some time ago I prepared Czech translation (via crowdin) and it is available in GRAV as of now.

However the translation is not good - the structure and logic inside is not flexible as it use English as a base. Czech language is slavic language and works with the semantic different way.

When I tried to create a translation (or maybe better - localization) I found some limits, which are not breakable and therefore translation looks very unprofessional.

As the translation is created as just “dictionary database” (see later for explanation) some phrases looks funny and in some cases you must switch to English to fully understand what is error message about.

In many ways the translation phrase is created as a group of joined words reflecting English grammar and it is not transferable to other languages (e.g. Czech language). This is I call dictionary database.

Just some examples :

The translation file starts with the part of INFLECTOR_PLURALS: INFLECTOR_SINGULAR: INFLECTOR_UNCOUNTABLE: INFLECTOR_IRREGULAR: INFLECTOR_ORDINALS:

which is valid for English. Or is possible to be used also in other langauges? Some documentation for it?

In many Slavic languages we have more words for plural e.g.

in EN - 0 pages, 1 page, 2 and more pages - just 2 variants in CZ - 0 stran, 1 strana, 2 - 4 strany, 5 and more stran - 3 variants

I know also that other languages like Slovak or Polish use the same. Now it is not integrated and even can not be managed somehow.

If we are going back to translation file - you can see that when there are translation of time units like hour/hours, minute/minutes etc. as we need 3 variants (1 hodina/2 hodiny/5 hodin)

The tricky translation is also when translating the names of months :

When we are talking about the month itself we can use words like Leden, Unor, Brezen (January, February, March). This is fine. But when we are writing date, you can not use that form of word, that means you need special set of words for dates.

So when we are talking about month, we can say Leden 2020 (January 2020) but for dates we must use 1. ledna 2020 (January 1st, 2020 or 1st January 2020). This is also not covered in the GUI translation (I know that dates are sometimes used from locales on the server, which can handle this)

So this is the translation of GRAV (frontend) but more problems with GRAV admin, as it use more strings and use more combinations and the file is much more complex and bigger.

I was a translator of e.g. Joomla and it was covered. So it is possible, but I feel that there was no direct demand of this functionality in GRAV. So is this the right time to request this?

I can help developers with more examples and even be a tester and fully understand that this is not a project for a week rather for months.

My proposal is to leave the model of joining standalone words to sentences and replace this by full phrases with variables as you can shift the variable inside the sentece and provide the best sentence construction.let me show you an example.

Situation : Provide a string with greeting of just logged in user. The sentence should be something like this :

"Welcome John Doe, nice to see you again on www.mysite.com!"

  1. Solution as implemented : Variables [User Name] [Website name]

Standalone strings translation file: GREETING_STRING: Welcome NICE_TO_SEE_YOU_AGAIN_ON: nice to see you again on

String to be shown in GUI : GREETING_STRING + " " + [User name] + "," + NICE_TO_SEE_YOU_AGAIN_ON + " " + [Website name] + "!"

  1. Solution firendly to translation Variables %1 which is User name %2 which is Website name

Standalone strings in translation file:

GREETING_STRING: Welcome %1, nice to see you again on %2!

String to be shown in GUI: GREETING_STRING

The second solution is much more convenient as it can bring enough context for translators and they have freedom in translating as I can prepare the translated string much better to suite the needs in my language e.g. translation of example could be done like this:

"Welcome John Doe, nice to see you again on www.mysite.com!"

"Vítejte na stránkách www.mysite.com uživateli John Doe!"

String for Czech language as shown:

GREETING_STRING: Vítejte na stránkách %2 uživateli %1!

In this special case you can see, that for me is important to switch variables comparing to English original as it sounds much better in my langauge. In model we have now implemented, this is impossible (it can be somehow changed in source code). In new model translator can do this without special support from developers and this is responsibility of translator.

Question 1 : Is this explanation clear? Question 2 : Is this acceptable from your side?

As I mentioned this before - this problem is not so big in GRAV itself as it contains just few strings, but rather bigger problem for Admin plugin.

And last argument - I am not a programmer a can not propose any code change just theory behind as I have done...

Activity icon
issue

geogeorgejoseph issue getgrav/grav-plugin-form

geogeorgejoseph
geogeorgejoseph

File uploading not working properly

Tring to upload file, but getting below errors

form.vendor.js:5 Uncaught TypeError: Cannot read properties of undefined (reading 'trim') at D.addedfile (form.vendor.js:5:11362) at D.value (form.vendor.js:5:1513) at D.value (form.vendor.js:5:25886) at HTMLInputElement. (form.vendor.js:5:17561)

Please give me a solution

Activity icon
issue

aleclerc7 issue comment getgrav/grav-premium-issues

aleclerc7
aleclerc7

[typhoon] DOC suggestion — Inheriting from Typhoon

Hello,

Here is a suggestion to add few details if someone inherits from Typhoon instead of using Copy. A few more steps are required to make things run when modifying CSS.

Here are the proposed additions. While writing this, I also created a theme from scratch to make sure this was all that was necessary. It might be possible that a line or two in tailwind.config.js are not required. (Like './available-classes.md',?)

Kind regards.

PS. Here is a .md file with the suggestions: suggestions.md.

In: Theme Modification / Create a Custom Theme from Typhoon

(1) Command line should be: (new-theme, not newtheme)

bin/plugin devtools new-theme

(2) Add the following text after the paragraph on "Copy". (Just before Modify the CSS.)

If you prefer to inherit from Typhoon and you want to configure your theme with the same features as Typhoon in Grav Admin Panel, you must copy the form: section of typhoon/blueprints.yaml into your new theme blueprints.yaml file. It is also recommended to copy the dependencies: section.

In : Theme Modification / Modify the CSS

(3) Maybe after the last instruction about "npm update", add another sub-section:

In your theme inherits from Typhoon

If you choose to inherit from Typhoon when creating your theme, a few more steps are required for NPM to work properly.

Before running npm install, do the following :

  1. From the Typhoon theme folder, copy the following files into your new theme's folder: tailwind.config.js, package.json, postcss.config.js

  2. In your new theme folder, modify tailwind.config.js to add your theme name, and add entries to point to Typhoon's resources.

content: normalize([ '../../config/**/*.yaml', '../../pages/**/*.md', './blueprints/**/*.yaml', '../typhoon/blueprints/**/*.yaml', './js/**/*.js', '../typhoon/js/**/*.js', './templates/**/*.twig', '../typhoon/templates/**/*.twig', './__your_new_theme_name__.yaml', '../typhoon/typhoon.yaml', './__your_new_theme_name__.php', '../typhoon/typhoon.php', './available-classes.md', '../typhoon/available-classes.md' ]),

  1. Finally, create a new file in css/site.css with the following content: @import '../../typhoon/css/site.css';

You will also be able to add your own CSS declarations in this file.

Now, if you run npm install and npm run build or npm run watch.

aleclerc7
aleclerc7

This is well integrated and flows very well. Great job; and thank you!

Activity icon
fork

gizmecano forked getgrav/grav-skeleton-mediator-site

⚡ Grav Skeleton Mediator
gizmecano MIT License Updated
fork time in 2 days ago
Activity icon
issue

zigojacko issue comment getgrav/grav-plugin-form

zigojacko
zigojacko

Can't get any reCaptcha to work in the form

When I add g-recaptcha-response to my form frontmatter, all it does is place an extra random field in my form in the frontend...

Screenshot_14

I've tried all three reCaptcha versions, each time with new keys from Google. This just doesn't seem to work at all...

Screenshot_15

zigojacko
zigojacko

@robhuijben can't really remember how I fixed this now but I think I reformatted my frontmatter and reCaptcha v3 has been working fine since then.

Activity icon
issue

petira issue comment getgrav/grav

petira
petira

Grav translation philosophy change

As I am using GRAV more and more and try to get more and more experience with it, I found, that translation model integrated into GRAV is not good. I am not talking about content but about GUI.

I am from Czech Republic and users there are very sensitive if the product is not available in local language - Czech language. Therefore some time ago I prepared Czech translation (via crowdin) and it is available in GRAV as of now.

However the translation is not good - the structure and logic inside is not flexible as it use English as a base. Czech language is slavic language and works with the semantic different way.

When I tried to create a translation (or maybe better - localization) I found some limits, which are not breakable and therefore translation looks very unprofessional.

As the translation is created as just “dictionary database” (see later for explanation) some phrases looks funny and in some cases you must switch to English to fully understand what is error message about.

In many ways the translation phrase is created as a group of joined words reflecting English grammar and it is not transferable to other languages (e.g. Czech language). This is I call dictionary database.

Just some examples :

The translation file starts with the part of INFLECTOR_PLURALS: INFLECTOR_SINGULAR: INFLECTOR_UNCOUNTABLE: INFLECTOR_IRREGULAR: INFLECTOR_ORDINALS:

which is valid for English. Or is possible to be used also in other langauges? Some documentation for it?

In many Slavic languages we have more words for plural e.g.

in EN - 0 pages, 1 page, 2 and more pages - just 2 variants in CZ - 0 stran, 1 strana, 2 - 4 strany, 5 and more stran - 3 variants

I know also that other languages like Slovak or Polish use the same. Now it is not integrated and even can not be managed somehow.

If we are going back to translation file - you can see that when there are translation of time units like hour/hours, minute/minutes etc. as we need 3 variants (1 hodina/2 hodiny/5 hodin)

The tricky translation is also when translating the names of months :

When we are talking about the month itself we can use words like Leden, Unor, Brezen (January, February, March). This is fine. But when we are writing date, you can not use that form of word, that means you need special set of words for dates.

So when we are talking about month, we can say Leden 2020 (January 2020) but for dates we must use 1. ledna 2020 (January 1st, 2020 or 1st January 2020). This is also not covered in the GUI translation (I know that dates are sometimes used from locales on the server, which can handle this)

So this is the translation of GRAV (frontend) but more problems with GRAV admin, as it use more strings and use more combinations and the file is much more complex and bigger.

I was a translator of e.g. Joomla and it was covered. So it is possible, but I feel that there was no direct demand of this functionality in GRAV. So is this the right time to request this?

I can help developers with more examples and even be a tester and fully understand that this is not a project for a week rather for months.

My proposal is to leave the model of joining standalone words to sentences and replace this by full phrases with variables as you can shift the variable inside the sentece and provide the best sentence construction.let me show you an example.

Situation : Provide a string with greeting of just logged in user. The sentence should be something like this :

"Welcome John Doe, nice to see you again on www.mysite.com!"

  1. Solution as implemented : Variables [User Name] [Website name]

Standalone strings translation file: GREETING_STRING: Welcome NICE_TO_SEE_YOU_AGAIN_ON: nice to see you again on

String to be shown in GUI : GREETING_STRING + " " + [User name] + "," + NICE_TO_SEE_YOU_AGAIN_ON + " " + [Website name] + "!"

  1. Solution firendly to translation Variables %1 which is User name %2 which is Website name

Standalone strings in translation file:

GREETING_STRING: Welcome %1, nice to see you again on %2!

String to be shown in GUI: GREETING_STRING

The second solution is much more convenient as it can bring enough context for translators and they have freedom in translating as I can prepare the translated string much better to suite the needs in my language e.g. translation of example could be done like this:

"Welcome John Doe, nice to see you again on www.mysite.com!"

"Vítejte na stránkách www.mysite.com uživateli John Doe!"

String for Czech language as shown:

GREETING_STRING: Vítejte na stránkách %2 uživateli %1!

In this special case you can see, that for me is important to switch variables comparing to English original as it sounds much better in my langauge. In model we have now implemented, this is impossible (it can be somehow changed in source code). In new model translator can do this without special support from developers and this is responsibility of translator.

Question 1 : Is this explanation clear? Question 2 : Is this acceptable from your side?

As I mentioned this before - this problem is not so big in GRAV itself as it contains just few strings, but rather bigger problem for Admin plugin.

And last argument - I am not a programmer a can not propose any code change just theory behind as I have done...

petira
petira

Hi!

I agree with @svatas. Pluralization is different in the Czech language (and in others as well) and it is desirable to take it into account in translations.

I am also ready to be helped.

Activity icon
issue

svatas issue comment getgrav/grav

svatas
svatas

Grav translation philosophy change

As I am using GRAV more and more and try to get more and more experience with it, I found, that translation model integrated into GRAV is not good. I am not talking about content but about GUI.

I am from Czech Republic and users there are very sensitive if the product is not available in local language - Czech language. Therefore some time ago I prepared Czech translation (via crowdin) and it is available in GRAV as of now.

However the translation is not good - the structure and logic inside is not flexible as it use English as a base. Czech language is slavic language and works with the semantic different way.

When I tried to create a translation (or maybe better - localization) I found some limits, which are not breakable and therefore translation looks very unprofessional.

As the translation is created as just “dictionary database” (see later for explanation) some phrases looks funny and in some cases you must switch to English to fully understand what is error message about.

In many ways the translation phrase is created as a group of joined words reflecting English grammar and it is not transferable to other languages (e.g. Czech language). This is I call dictionary database.

Just some examples :

The translation file starts with the part of INFLECTOR_PLURALS: INFLECTOR_SINGULAR: INFLECTOR_UNCOUNTABLE: INFLECTOR_IRREGULAR: INFLECTOR_ORDINALS:

which is valid for English. Or is possible to be used also in other langauges? Some documentation for it?

In many Slavic languages we have more words for plural e.g.

in EN - 0 pages, 1 page, 2 and more pages - just 2 variants in CZ - 0 stran, 1 strana, 2 - 4 strany, 5 and more stran - 3 variants

I know also that other languages like Slovak or Polish use the same. Now it is not integrated and even can not be managed somehow.

If we are going back to translation file - you can see that when there are translation of time units like hour/hours, minute/minutes etc. as we need 3 variants (1 hodina/2 hodiny/5 hodin)

The tricky translation is also when translating the names of months :

When we are talking about the month itself we can use words like Leden, Unor, Brezen (January, February, March). This is fine. But when we are writing date, you can not use that form of word, that means you need special set of words for dates.

So when we are talking about month, we can say Leden 2020 (January 2020) but for dates we must use 1. ledna 2020 (January 1st, 2020 or 1st January 2020). This is also not covered in the GUI translation (I know that dates are sometimes used from locales on the server, which can handle this)

So this is the translation of GRAV (frontend) but more problems with GRAV admin, as it use more strings and use more combinations and the file is much more complex and bigger.

I was a translator of e.g. Joomla and it was covered. So it is possible, but I feel that there was no direct demand of this functionality in GRAV. So is this the right time to request this?

I can help developers with more examples and even be a tester and fully understand that this is not a project for a week rather for months.

My proposal is to leave the model of joining standalone words to sentences and replace this by full phrases with variables as you can shift the variable inside the sentece and provide the best sentence construction.let me show you an example.

Situation : Provide a string with greeting of just logged in user. The sentence should be something like this :

"Welcome John Doe, nice to see you again on www.mysite.com!"

  1. Solution as implemented : Variables [User Name] [Website name]

Standalone strings translation file: GREETING_STRING: Welcome NICE_TO_SEE_YOU_AGAIN_ON: nice to see you again on

String to be shown in GUI : GREETING_STRING + " " + [User name] + "," + NICE_TO_SEE_YOU_AGAIN_ON + " " + [Website name] + "!"

  1. Solution firendly to translation Variables %1 which is User name %2 which is Website name

Standalone strings in translation file:

GREETING_STRING: Welcome %1, nice to see you again on %2!

String to be shown in GUI: GREETING_STRING

The second solution is much more convenient as it can bring enough context for translators and they have freedom in translating as I can prepare the translated string much better to suite the needs in my language e.g. translation of example could be done like this:

"Welcome John Doe, nice to see you again on www.mysite.com!"

"Vítejte na stránkách www.mysite.com uživateli John Doe!"

String for Czech language as shown:

GREETING_STRING: Vítejte na stránkách %2 uživateli %1!

In this special case you can see, that for me is important to switch variables comparing to English original as it sounds much better in my langauge. In model we have now implemented, this is impossible (it can be somehow changed in source code). In new model translator can do this without special support from developers and this is responsibility of translator.

Question 1 : Is this explanation clear? Question 2 : Is this acceptable from your side?

As I mentioned this before - this problem is not so big in GRAV itself as it contains just few strings, but rather bigger problem for Admin plugin.

And last argument - I am not a programmer a can not propose any code change just theory behind as I have done...

svatas
svatas

Dear all,

after while I am asking about this improvement again. It was first mentioned in June 2020, but no real output from this until now. Are there any plans how to solve this? I fully understand what is behind and an effort which must be invested into this. But from my perspective this is a big problem of GRAV as of now.

I fully understand that for english speaking person this is not so important, but for the rest of non english speakers this could be a pain. For me is this very sad as there was no real activity done to improve the status.

Once again - is there any chance to change the philosophy and bring this project further?

Activity icon
issue

IamSAB issue getgrav/grav

IamSAB
IamSAB

Checkboxes validation bug

The checkboxes field only is valid when all options are checked. Selecting only some or no options will render it invalid and the form won't submit.

hobbies:
  type: checkboxes
  label: Hobbies
  options:
    soccer: Soccer
    rugby: Rugby
    biking: biking
   swimming: Swimming

As you see, there is any validation defined, the field is not even required. Is that a known bug?

I use that field type inside a flex form in the admin backend,

Activity icon
issue

w00fz issue comment getgrav/grav-premium-issues

w00fz
w00fz

[nextgen-editor] Editor is appearing two times with the same content

Since the last update the editor now appears twice, with the same content.

It doesn't seem to do it for new pages - only existing. I can't work out why that is.

w00fz
w00fz

@slwa-epowell I also double checked and the vendor JS file is not 8MB+ but around 1MB. This is the file that loads in your admin. That said, I am noticing I am including the sourcemap file with the package, which is about 5MB and that is definitely superfluous. I will make sure to get rid of that in the next release so you get a much slimmer package, thanks for noticing!

Activity icon
issue

w00fz issue comment getgrav/grav-premium-issues

w00fz
w00fz

[nextgen-editor] Editor is appearing two times with the same content

Since the last update the editor now appears twice, with the same content.

It doesn't seem to do it for new pages - only existing. I can't work out why that is.

w00fz
w00fz

I'm very confused about this one, I cannot seem to be able to replicate the double editor. Can you add a little bit more context about the setup?

  1. Are you using a custom blueprint or is it a default page?
  2. What theme are you using?
  3. Do you have additional plugins adding fields in your edited Page?

If you can also share a screenshot or anything that can help me reproduce this, that would be greatly appreciated!

Activity icon
issue

w00fz issue comment getgrav/grav-premium-issues

w00fz
w00fz

[typhoon] DOC suggestion — Inheriting from Typhoon

Hello,

Here is a suggestion to add few details if someone inherits from Typhoon instead of using Copy. A few more steps are required to make things run when modifying CSS.

Here are the proposed additions. While writing this, I also created a theme from scratch to make sure this was all that was necessary. It might be possible that a line or two in tailwind.config.js are not required. (Like './available-classes.md',?)

Kind regards.

PS. Here is a .md file with the suggestions: suggestions.md.

In: Theme Modification / Create a Custom Theme from Typhoon

(1) Command line should be: (new-theme, not newtheme)

bin/plugin devtools new-theme

(2) Add the following text after the paragraph on "Copy". (Just before Modify the CSS.)

If you prefer to inherit from Typhoon and you want to configure your theme with the same features as Typhoon in Grav Admin Panel, you must copy the form: section of typhoon/blueprints.yaml into your new theme blueprints.yaml file. It is also recommended to copy the dependencies: section.

In : Theme Modification / Modify the CSS

(3) Maybe after the last instruction about "npm update", add another sub-section:

In your theme inherits from Typhoon

If you choose to inherit from Typhoon when creating your theme, a few more steps are required for NPM to work properly.

Before running npm install, do the following :

  1. From the Typhoon theme folder, copy the following files into your new theme's folder: tailwind.config.js, package.json, postcss.config.js

  2. In your new theme folder, modify tailwind.config.js to add your theme name, and add entries to point to Typhoon's resources.

content: normalize([ '../../config/**/*.yaml', '../../pages/**/*.md', './blueprints/**/*.yaml', '../typhoon/blueprints/**/*.yaml', './js/**/*.js', '../typhoon/js/**/*.js', './templates/**/*.twig', '../typhoon/templates/**/*.twig', './__your_new_theme_name__.yaml', '../typhoon/typhoon.yaml', './__your_new_theme_name__.php', '../typhoon/typhoon.php', './available-classes.md', '../typhoon/available-classes.md' ]),

  1. Finally, create a new file in css/site.css with the following content: @import '../../typhoon/css/site.css';

You will also be able to add your own CSS declarations in this file.

Now, if you run npm install and npm run build or npm run watch.

Activity icon
issue

w00fz issue getgrav/grav-premium-issues

w00fz
w00fz

[typhoon] DOC suggestion — Inheriting from Typhoon

Hello,

Here is a suggestion to add few details if someone inherits from Typhoon instead of using Copy. A few more steps are required to make things run when modifying CSS.

Here are the proposed additions. While writing this, I also created a theme from scratch to make sure this was all that was necessary. It might be possible that a line or two in tailwind.config.js are not required. (Like './available-classes.md',?)

Kind regards.

PS. Here is a .md file with the suggestions: suggestions.md.

In: Theme Modification / Create a Custom Theme from Typhoon

(1) Command line should be: (new-theme, not newtheme)

bin/plugin devtools new-theme

(2) Add the following text after the paragraph on "Copy". (Just before Modify the CSS.)

If you prefer to inherit from Typhoon and you want to configure your theme with the same features as Typhoon in Grav Admin Panel, you must copy the form: section of typhoon/blueprints.yaml into your new theme blueprints.yaml file. It is also recommended to copy the dependencies: section.

In : Theme Modification / Modify the CSS

(3) Maybe after the last instruction about "npm update", add another sub-section:

In your theme inherits from Typhoon

If you choose to inherit from Typhoon when creating your theme, a few more steps are required for NPM to work properly.

Before running npm install, do the following :

  1. From the Typhoon theme folder, copy the following files into your new theme's folder: tailwind.config.js, package.json, postcss.config.js

  2. In your new theme folder, modify tailwind.config.js to add your theme name, and add entries to point to Typhoon's resources.

content: normalize([ '../../config/**/*.yaml', '../../pages/**/*.md', './blueprints/**/*.yaml', '../typhoon/blueprints/**/*.yaml', './js/**/*.js', '../typhoon/js/**/*.js', './templates/**/*.twig', '../typhoon/templates/**/*.twig', './__your_new_theme_name__.yaml', '../typhoon/typhoon.yaml', './__your_new_theme_name__.php', '../typhoon/typhoon.php', './available-classes.md', '../typhoon/available-classes.md' ]),

  1. Finally, create a new file in css/site.css with the following content: @import '../../typhoon/css/site.css';

You will also be able to add your own CSS declarations in this file.

Now, if you run npm install and npm run build or npm run watch.

started
started time in 3 days ago
Activity icon
issue

hotdoy issue comment getgrav/grav-premium-issues

hotdoy
hotdoy

[algolia-pro] Remove VUE devtool advertising from console

You guys probably have it installed but when you don't, VUE seems to console.log this message.

image

Activity icon
issue

hotdoy issue comment getgrav/grav-premium-issues

hotdoy
hotdoy

[algolia-pro] input[type="search"] appearance

I had some occurrence of input type="search" appearance going bonker and showing the default blue X. (I think you have a reset in learn.getgrav).

Anyways, I added this to fix it.

[data-algolia-pro] input[type="search"] {
    -webkit-appearance: textfield;
}

[data-algolia-pro] input[type="search"]::-webkit-search-decoration,
[data-algolia-pro] input[type="search"]::-webkit-search-cancel-button,
[data-algolia-pro] input[type="search"]::-webkit-search-results-button,
[data-algolia-pro] input[type="search"]::-webkit-search-results-decoration { 
    display: none; 
}
hotdoy
hotdoy

Oups. Missed the notification. Yeah it's good @w00fz thanks!

Jan
20
4 days ago
Activity icon
issue

drzraf issue comment getgrav/grav

drzraf
drzraf

PHP 7.4 opcache preloading script

To profit from PHP 7.4 opcache preloading, Grav could provide a file loader (= cache warmer) Symfony provides one and snippets exist for WordPress.

Couldn't Grav provide one such preloader script to be referenced by php.ini so that it's possible to benefit from the enhanced performances?

drzraf
drzraf

Still interesting (possibly providing significant page load improvement by reducing bootstrap/autoload time)

Previous