Viewing 15 posts - 1 through 15 (of 15 total)
  • Author
    Posts
  • #1418201

    Hello

    Unfortunately, the problem reported in another thread of mine has occurred again and again affects several posts.

    Unfortunately, we cannot apply the filter ‘avf_post_css_create_file’ with false, as otherwise the HTML structure is changed (as the style tags are inserted before the respective element). Is there a way that the CSS rules are bundled in the head rather than before the respective element?

    Many thanks
    blende64

    #1418606

    Hey Jeannette,
    Thank you for your patience, but unfortunately if you use the filter ‘avf_post_css_create_file’ the css will be inline.
    Have you tried the option Enfold Theme Options ▸ Performance ▸ CSS file merging and compression ▸ Use minified theme CSS files without merging this doesn’t merge or add the css inline.

    Best regards,
    Mike

    #1418891

    Hi Mike

    Thank you for your tip.
    What should this setting do? When I change the setting as suggested, I can’t see any difference. I do see that many Enfold files have now been minified, but the post CSS is still missing from some posts and is output as an unminified file for others.

    Kind regards
    Jeannette

    #1418920

    Hi,
    It looks like the post css files are also used with that setting, so the the filter ‘avf_post_css_create_file’ will be the only way to not use the post files.
    In your other thread it looks like the issue is that your pages are translated into new pages, have you tried opening the new pages in the editor and resaving them, I would expect this to generate the correct post css files for the new pages.
    Why does the inline css cause a problem for your translated pages? Perhaps we can overcome this part of the issue.

    Best regards,
    Mike

    #1418924

    Hi Mike
    Not quite: if the post CSS is missing from a post, this affects the original language as well as all translations.

    Suppose I have the following structure before I set the filter to false:

    <div class="entry-content-wrapper">
    	<div class="flex_column"></div>
    	<div class="flex_column"></div>
    	<div class="flex_column"></div>
    </div>

    After setting the filter to false, the structure appears as follows:

    <div class="entry-content-wrapper">
    	<style></style>
    	<div class="flex_column"></div>
    	<style></style>
    	<div class="flex_column"></div>
    	<style></style>
    	<div class="flex_column"></div>
    </div>

    The selector .flex_column:nth-child(2n) would have selected every other column before setting the filter. After the filter value is changed, the selector applies to every column. Accordingly, unwanted changes to the design are the result.

    Opening and resaving a post fixes the problem for that post. Whereas each post must be resaved in all languages. Unfortunately, the missing post CSS can only be detected using the browser console. And I can’t expect the unsavvy customer to check the browser console after each post, unfortunately. However, if the missing CSS persists, it increases load time and generates an unnecessary number of 404 errors.

    I just checked the server log again when the post with the missing post CSS was created. Unfortunately, there are no errors in it. Do you see any way I could get to the bottom of the underlying problem?

    Thanks a lot!

    #1418969

    Hi,

    Thank you for the info.

    We may have to access the site in order to properly inspect the issue. Please provide the WP and S/FTP details in the private field. Is there a staging or development version of the site?

    Best regards,
    Ismael

    #1419008

    Hi

    I just set up a staging environment. You can find the access data in the private field. The problem: the missing post CSS were apparently automatically generated in the staging environment. Why, I can not explain. I proceeded as follows:
    – Created ZIP archive of the files on productive system
    – Created dump of the DB on productive system
    – Uploaded ZIP archive to staging system and unpacked it
    – Imported dump of the DB on staging system
    – Replaced domain with wp search-replace

    I did not do anything else. Now when I call the URL of a post with missing post css in the staging environment the post CSS is present. In contrast, this is still missing from the corresponding post on the live system. And is also actually not present in the file system of the server. In the private field you can find the URL of such a post.

    Kind regards,
    Jeannette

    #1419048

    Hi,

    Thanks for the login credentials.

    As you said: the staging site works as expected.

    When saving theme options the post css files get invalidated (this happens in database) and are regenerated when a page is loaded in front.

    You can check this on your staging site with ftp in folder /wp-content/uploads/dynamic_avia/avia_posts_css/.
    You need to reload theme options page after save to start a cron job to delete the post css files and also reload (“aktualisieren”) the directory in your ftp client.

    Checking the source text of your productive system page there are the correct links to the post css file (see private content).

    It seems, that the files could not be created on your production site.

    Can you recheck if there are limitations in the filesystem ?
    Are cron jobs enabled?
    There is folder /wp-content/uploads/avia_posts_css – this is an outdated folder that you can delete (was moved inside /dynamic_avia.
    Can you scan your filesystem, if you find post-37241.css somewhere.

    Best regards,
    Günter

    #1419076

    Hi Günter

    Thank you very much for your detailed answer. This provides a lot of clarity regarding the creation of the post CSS files. Also, I now know how to have all post CSS files recreated automatically.

    I renamed the folder “avia_posts_css” on the staging system and could see that the post CSS files were logically missing from all posts afterwards. When I saved the Enfold settings again, the post CSS files were successfully regenerated the first time the respective post was called.

    I could not find the missing post CSS anywhere on the server.
    Cronjobs are enabled and work in general. However, we recently found out that a task of a plugin occasionally exceeded the maximum execution time in the past. Possibly this also caused the problem with the missing post CSS files?

    I am not aware of any file system limitations. Also, the creation of the files seems to work in principle, as for example with the latest post the post CSS was created successfully.

    A new post will be published in the next few days. I’ll be happy to let you know if it worked then. If so, I hope that this will remain so in the future.

    Kind regards
    Jeannette

    #1419170

    Hi Jeannette,

    Thank you for the feedback.

    I will leave this topic open.

    Enjoy the theme and have a great day.

    Best regards,
    Günter

    #1419179

    Hi Günter

    Today a new post was published and the post CSS was generated successfully. Let’s hope that this will continue. In any case, we will not invest any more effort in it for the time being.

    And how we enjoy the theme. This is the foundation of many of our websites and we always like to rely on it.

    Kind regards
    Jeannette

    #1419234

    by the way: to avoid this with nth-child use instead nth-of-type:
    https://tympanus.net/codrops/css_reference/nth-of-type/

    #1419265

    Hi Guenni007

    Thanks for the tip. That’s right, I could significantly minimize the problem with this. I will definitely take this into account for future projects.

    Kind regards
    Jeannette

    #1419301

    Hi,
    Glad Günter was able to help and it sounds like this is working well for you now, unless there is anything else we can help with on this issue, shall we close this then?

    Best regards,
    Mike

    #1419302

    Hi

    Yes, you can close it. Thanks again.

    Kind regards
    Jeannette

Viewing 15 posts - 1 through 15 (of 15 total)
  • The topic ‘Post CSS missing again’ is closed to new replies.