For the gem 'middleman-blog' is there a way to disable the generation of calendar pages?
Is there also an option to target the disabling of specific calendar pages, such as month and day pages?
I've tried looking at the source on Github, but there is no indication of such a feature.
When on middleman local/preview server (middleman server), look up the settings in your middleman configuration at <host>/__middleman/config. In there check for the :calendar_template setting under configurations for :blog, if it's not nil then set it to nil in your config.rb. It's similar for day, month and yearly pages.
Example :
// File : config.rb
activate :blog do |blog|
blog.current_template = nil
end
Related
since January 2022 there is a court decision in germany which states that using Google Fonts over their web api is no longer data protection compliant.
Spartacus requests the Open Sans font initially by default. The font url is defined in the /_variables.scss of the sparta theme.
Unfortunately I wasn´t able to find a way to overwrite this variable or prevent the storefront from requesting the font in any way.
There should be any option to not load this font initially. Not only because this is an DSGVO topic but also to get rid of unnecessary requests at initial load.
Does anyone have an idea how to solve this or is there any recommendation from the Spartacus Team?
With that said above in the comments section,
you have 3 options:
1 - wait for the backport to the maintenance branch(es), and upgrade accordingly
2 - create your own custom package from the Spartacus source code, and update the libraries that imports the entire #import '~#spartacus/styles/scss/app';. You can can change it to the same one found in this pull request
3 - NOT ideal, but in your shell app, you can remove the stylesheets that causes those problems from the "styles" array property in angular.json, and/or remove the import to the styles on the respective package, and copy the styles from source to the stylesheet themselves.
The affected libraries are cart, order, and epd-visualization.
I have customized the layout of sales order template ( added footer and header, formatted content etc. ). For this i created a new module and installed it. When i use this module locally (mac os), i am receiving the sales order document as pdf in the way i set it up. When using this module on a server and all changes do not apply at all. I can see that the module is installed, loaded and also if i switch the PDF-Report to HTML i can see that the Layout is set.
There are no 404 Errors in Logfile, so i am somehow stuck
As far as i understood the PDF File is a rendered HTML-File, therefore i am obviously missing some information here.
So my question is, where can i check what layout is used to generate the PDF-File?
Thanks for any help on that!
After finally finding something via more searches i found the solition which i want to share:
It is important to understand that if odoo is running public on any other port than 8069 ( portforwarding etc. ) this issue will always occur.
Generating the pdf will try to find needed assets on the public port which will not lead where needed.
The Solution is so easy but somehow i wasnt able to find it easily:
All you need to do is to set a proper url for report generation.
Goto -> Settings -> Parameters -> System Parameters
and add:
key: report.url
value: http://localhost:8069
localhost is here the correct domain, do not change this, so the machine will call the report url on itself.
Can you check your report layout in Settings ->Technical Settings ->Actions->Reports then search for your report and check qweb views
I also faced the same problem, struggled for a long period. After reading #patrick.tresp explanation I understood the reason.
For my case, I made made the odoo port (8069) as the default port, which made the base url as the localhost (domain.com) without the port number. However report url is not detecting the port, hence the problem occurs.
When I explicitly defined the report url, the problem get sorted.
i.e., Goto
Settings -> Parameters -> System Parameters
and add:
key: report.url
value: http://domain.ext:8069
I have TRAC 1.0.1 running.
For my tickets I would like to have a DueDate. Entering the DueDate should be done by using a DatePicker. Because it is convenient, and you can not enter wrong values.
I added following plugin to TRAC: http://trac-hacks.org/wiki/DateFieldPlugin
The description says, that it provides validation for custom fields and a DatePicker for Milestone and Ticket fields.
My trac.ini configuration file looks like this:
[ticket-custom]
duedate1 = text
duedate1.date = true
duedate1.date_empty = true
duedate1.label = Due Date
duedate1.order = 4
duedate1.value = DD-MM-YYYY
[datefield]
first_day = 1
format = dmy
separator = -
TRAC is now checking the input against the format. But what I really want is a DatePicker that pops up and lets me choose the date.
Any help is appreciated.
If the input is being validated but there is no datepicker it sounds like a client side JS / browser problem.
I just created a new Trac env, added the DateFieldPlugin, copied your [ticket-custom]
and [datefield] ini configuration and it seemed to work out of the box just fine. For example on /newticket I can see a datepicker for the Due Date field (using Firefox at least). Given that, all I can really do is give some more details which might help us debug your problem.
The datepicker is added via JavaScript. If you are running Trac 1.0 then you don't need to worry about jQuery or jQuery UI as Trac core now ships with these dependencies. You can see that by looking at the scripts tab in Firebug etc. when you are running tracd. Are you serving your own jQuery or jQuery UI scripts which might be conflicting? Are there any errors shown on the Firebug console tab?
The plugin serves extra JS files when you request certain pages in Trac, including /newticket and /ticket. You should also be able to see these scripts being served in Firebug etc. Is that true for you?
If you inspect the HTML in the ticket.html template displayed on /newticket you should also see something like this for the Due Date input
<input type="text" class="datepick hasDatepicker" value="MM-DD-YYYY" name="field_due_date1" id="field-due_date1">
Note the two datepick and hasDatePicker classes are what tell JS to to render a jQuery Datepicker dialog. Does your custom field have these classes? The plugin should be adding them for you (inside the post_process_request())
If all that is the same for you then maybe it is a browser problem?
While the plugin way was ok, when there was no other way, now it is only second best, because of all the limitations of storing date/time as formatted string instead of POSIX (micro)seconds, just like for other native Trac time fields.
There is a better way: Custom date/time field support has entered Trac core since 1.1.1 ("unstable" development branch moving towards next stable 1.2).
At least if you foresee heavy use and/or long term Trac deployment, you'll appreciate adding true timestamps to your db right from the start. It provides you with the best possible experience like date picker UI, full time zone and TracQuery support, even future time constraints ('nextday', 'nextweek', etc.) are possible right now.
A last note regarding Trac code stability: For what its worth I'm using true custom time fields support via patches in production since 2009 (Trac 0.13dev), runs smoothly in applications with 30.000+ tickets by now.
I am having some issues with a BigCommerce theme. It is an exact copy of a working theme, but on the new site, the mini basket/cart always shows $29.00 no matter what is in the cart (site is also set up to use £)
The issue lies with %%LNG_SideCartTotalCost%%.
Whats odd is that I checked the language file (via the url) and the text for this variable should be:
"Your sub total is <strong>%s</strong>."
Yet its coming through as:
"Total: <strong>%s</strong>."
I'm unsure who this was changed (the site is a clients, who has had work done by other developers)
How would someone change this language variable in BigCommerce? I was under the impression you could only edit themes, and not code?
So, any thoughts on how to fix this?
Thanks!
I work at Bigcommerce. The file you will need to edit is the sidecartcontents.html file. You are able to customize HTML, CSS, Javascript and JQuery. The only thing you don't have access to is any global variables that require PHP files. As a SaaS platform, we don't provide our clients access to the PHP files.
Turns out is was an issue with the language file. The support staff had to update it.
Thanks to everyone in advance -
So I have been banging on this issue for quite a while now and have burned through all my options. My current approach to canceling css requests is with nsIRequest.cancel inside of nsIWebProgressListener.onStateChange. This works most of the time, except when things are a little laggy a few will slip through and jump out of the loadgroup before I can get to them. This is obviously a dirty solution.
I have read through the following links to try and get a better idea of how to disable css before a nsIRequest is created...no dice.
https://developer.mozilla.org/en/Document_Loading_-_From_Load_Start_to_Finding_a_Handler
https://developer.mozilla.org/en/The_life_of_an_HTML_HTTP_request
https://developer.mozilla.org/en/Bird's_Eye_View_of_the_Mozilla_Framework
How do I disable css via presentation objects/interfaces? Is this possible? Inside of nsIDocShell there are a few attributes that kind of imply you can disable css via the browsers docshell - allowPlugins, allowJavascript, allowMetaRedirects, allowSubframes, allowImages.
Any suggestions?
Thanks,
Sam
The menu option that disables style sheets uses a function
setStyleDisabled(true)
so you probably can just call this function whenever new browser tab is created. Style sheets are still requested from server, but not applied. This function is not very sophisticated and doesn't mess with nsIRequest, source:
function setStyleDisabled(disabled) {
getMarkupDocumentViewer().authorStyleDisabled = disabled;
}
Digging in Web Developer Toolbar source code I have noticed that their "disable stylesheets" function loops trough all document.styleSheets and sets the disabled property to true, like:
/* if DOM content is loaded */
var sheets = document.styleSheets;
for(var i in sheets){ sheets[i].disabled = true; }
So if the key is to not apply CSS to pages, one of the above solutions should work. But if you really need to stop style sheets from being downloaded from servers, I'm affraid nsIRequest interception is your only option.
Set permissions.default.stylesheet to 2 and voilà!
You can actually use the permissions manager to block or allow stylesheets on a host-by-host basis.
Unfortunately there doesn't seem to be a simple flag like allowImages. The bugzilla adding for that is https://bugzilla.mozilla.org/show_bug.cgi?id=340746. You can now vote for it using the new bugzilla voting functionality. You can also add yourself to the CC list to be notified if anyone ever works on it.
A related request is to just give us basic HTML parsing support, which may be what you are trying to do. Unfortunately that isn't supported yet either, but you can vote/track the bugzilla for that at https://bugzilla.mozilla.org/show_bug.cgi?id=102699.
So the only workable solution seems to be some sort of interception as #pawal suggests. Here is a link that talks about the basics of interception to at least get you/us started https://developer.mozilla.org/en/XUL_School/Intercepting_Page_Loads. It lists several options that I list below.
These first few seem to just be at the page/document level so I don't think they help:
Load Events (addEventListener load)
Web Progress Listeners (nsIWebProgressListener) - I tried this approach, it only seems to be called for the page itself, not for content within the page.
Document Loader Service - A global version of nsIWebProgressListener so I think it has the same problem (page level only)
That leaves two others I have not tried yet. They work globally so you would need to filter them to just the browser/pages you care about.
HTTP Observers - Seems like it might work, need to verify it calls back for CSS
Content Policy - Seems like the best option to me since it explicitly is called for CSS, someday I hope to try it :)