Ready to give up on themes

I’m having all sorts of difficulties customising my invoices with themes. With the original invoice templates, I invested quite a lot of time creating a heavily customised CSS layout. I was able to create a table with both ex-GST and inc-GST columns, and style the whole thing beautifully with CSS.

It all fell apart with the new themes. The first challenge was to work out how to reference variables that don’t have specific names, but are hidden within tables. I’ve done that in some cases with array references, like table.totals[0].text. I’ve added a GST inclusive column with {{ row.cells[3].text | times:1.1 | round: 2 }}. It’s messy, but it mostly works. (It doesn’t work on a negative value.)

So now, my invoices should be looking mostly as they did before, but they don’t. CSS styling of tables seems to be where things are falling apart. The same code displays correctly in a web browser, leading me to conclude that CSS is somewhat broken in Manager themes.

To be frank, I’m ready to give up on themes. Can we please have invoice templates back? They did exactly what I wanted them to. I’m willing to go back to the most recent version which still had backwards compatibility and stay there if you don’t want to reintroduce backwards compatibility. Is this something I can still download?

If you are writing CSS within <style> tag, that is not supported. CSS must be within style attribute of individual HTML tags and even then, only certain styles are supported.

Previously CSS was fully supported but it came at the cost. Back then Manager had to connect to 3rd-party server to convert HTML to PDF. This was slow and came with privacy concerns. The latest version is able to produce PDF files locally without connecting to 3rd-party server.

Why Manager can’t support entire CSS set? It could but that would mean to embed Chromium which is about 50 MB. In other words, Manager download size would go from 10 MB to 60 MB just to support this one marginal feature. It’s just not worth it.

So the long-term solution is to just keep improving internal PDF generator so it can support more of HTML/CSS subset as time goes.


Yes, I’m using an internal style sheet with the <style> tag. Keeping style (CSS) separate from structure (HTML) is generally considered good practice and it’s so much easier to maintain, so that’s a shame to hear it’s not supported anymore. (I wasn’t aware that previous versions were connecting to a third-party server.)

Can you not use native WebKit for the macOS version, which is a part of the OS? Is the difficulty in supporting multiple platforms?

Pretty much this. Keep in mind, you can already generate PDF using WebKit by clicking on Print button (instead of PDF button) and making WebKit to print to PDF. However this is a workaround.

Overall internal PDF generator is way to go because themes will work (or be broken) consistently across all editions and all operating systems.

Okay thanks for explaining. I’m going through my code bit by bit and replacing with inline styles in table elements, and that seems to be fixing things.

Regarding my other issue—the difficulty of referencing variables, is there an easier way than than what I’m doing? Previously I could add a GST inclusive column with this:
{{ | }}

But now I have to do something like this:
{{ row.cells[3].text | times:1.1 | round: 2 }}

It feels kludgy. Is there a better way?

1 Like

Before you even dive into this, why do you need a column to show GST inclusive price and GST exclusive price on each line item? It’s certainly not required by law.

Just because I thinks it makes for a really clear invoice. But that’s not the only way I customised the design. My invoice total and due date aren’t in a conventional table. It’s a design I created before I started using Manager, and one that my clients are used to. I already compromised on some other areas of the design, in that I can’t separate out Billable Expenses from other items, or include an hourly time column.

Here’s a sample of the original design, so you can see what I was trying to match…

You can rearrange line items by dragging the double-headed arrow 07 PM to the left of the lines.

And if you are using the Billable Time tab, hours for each time entry appear on the sales invoice:

47 PM

Headings within the sales invoice can be inserted by entering the heading text into the Description field and leaving the rest of the line item blank. Give it a try.

My view is that invoice theme shouldn’t be introducing new columns. It should be changing appearance of existing columns. So I’m not going to make it easier to introduce new columns but I do strive to make appearance customizations easier.

Maybe in future, Manager will have ability to show both columns (price tax incl. and price tax excl.) then you can achieve your look with ease.

As for separation of billable time from other items, eventually there will be a concept of having line item groups within invoice. Then your invoice theme can style line item groups differently from individual line items as you have it in your screenshot.

So yeah, what are you trying to achieve is still out of reach to be done easily with Manager. But there are features in the pipeline which will eventually take Manager there.

As for having invoice total and due date shown like that, that’s already possible. I assume you have been able to figure it out?

Thanks for the tips Tut. These are fairly crude workarounds which don’t let you format the tables as I have shown (not without some serious JavaScript anyway), but I’m not too worried about these things. I wasn’t able to do them in the earlier versions of Manager either and just accepted that. (The other benefits of Manager made me happy to switch.)

Ah yes, I think I knew this when I started using Manager, but decided that Manager couldn’t replace my project management software, so I never did start using Billable Time. Again, I’m not too worried about it.

No worries.

Yes and no. This is the only way I’ve been able to figure out how to isolate the data:

Invoice total:
{{ table.totals[2].text | money_without_currency }}

Payment due by:
{{ fields[1].text | date_to_string }}

As I said, it feels kludgy, but it works.

But my CSS layout is still breaking here. Bit by bit, I’m duplicating my original CSS into each separate HTML element, but either I’ve missed something, or I’ve hit a limitation of Manager’s CSS. That part is really quite frustrating. I think <style> tag support is a next-to-essential feature when documents are HTML based. Table-based layout belongs to last century, and inline styles are only marginally better. Having to download an extra 50 MB would be the least of my worries, but I appreciate others may feel differently.

1 Like

This is not really future-proof. It could break with new updates.

The correct way would be to loop through all fields or totals to find the ones with labels you want to work with. That’s a bit more complicated. The issue with Liquid markup is that you can’t have array which can be hash at the same time.

If it would be possible, you could just write… {{ fields["Due Date"].text | date_to_string }} which would be more future-proof. I still want to offer this facility as it would make things so much simpler.

I don’t agree with this statement. Using tables for layout is totally fine and it is what I recommend for themes. Also, keep in mind, even though themes are written in HTML, the ultimate output is PDF, not screen.

This is complicated topic. I wish there would be generally accepted markup language for printed documents but there isn’t. HTML is the best we have which is unfortunate because HTML was designed for screen, not for printing.

1 Like

Yes, that would be a lot better.

Something like this would be even better if it were possible:

Okay, we have a very different design philosophy then. I used to build websites using table-based layouts before there was CSS, but the good old days really weren’t very good. Sure, tables are kind of solid and predictable, but want to move an element somewhere? Have one element overlapping another? Fuhgeddaboudit.

Tables are best at doing what they were designed for: storing tabular data. HTML is best at structuring content. And CSS is best for layout and design. When your layout is table-based, your content is all mixed up with your presentation, making it harder to work with both.

That’s part of what makes your default themes so hard to read and make sense of. Compare it to something like this:

<div id="logo">
	{% if business.logo != null %}
		<img src="{{ business.logo }}"/>
	{% endif %}

<div id="business_details">
	<p>{{ }}<br>
	{{ business.address }}</p>
	<p>ABN: {{ business.identifier }}</p>

<div id="recipient_details">
	<p>{{ }} {{ recipient.code }}<br>
	{{ recipient.address | newline_to_br }}</p>
	<p>{{ recipient.identifier }}</p>

<div id="document_fields">
	{% for field in fields %}
	<p>{{ field.label }}: {{ field.text }}</p>
	{% endfor %}

<h1>{{ description }}</h1>

		{% for column in table.columns %}            
		<th>{{ column.label }}</th>
		{% endfor %}

	{% for row in table.rows %}
		{% for cell in row.cells %}
		<td>{{ cell.text | newline_to_br }}</td>
		{% endfor %}
	{% endfor %}
	{% for total in table.totals %}
		<td colspan="{{ table.columns | size | minus:1 }}" >{{ total.label }}</td>
		<td>{{ total.text }}</td>
	{% endfor %}

<div id="custom_fields">
	{% for field in custom_fields %}
	<p>{{ field.label }}: {{ field.text }}</p>
	{% endfor %}

So much easier to understand!

True. There’s ye olde PostScript (and PDF of course), but imagine trying to code in that! Yuck.

I happen to think HTML are CSS are pretty awesome, albeit far from perfect. I just think they need to play to their strengths.

1 Like

Yeah, I’ve been also around 20 years ago when there was no CSS and presentation was defined within HTML attributes.

I don’t think we have different philosophy. If you are making a website, you are better not to use tables for presentation if you want your website to be responsive to different screen sizes. I agree with you on that.

Right now, the whole theme needs to be written as one big table. I’d like to change that for simplicity reasons but it’s not like I consider it wrong as it is now. I do plan to add support for <header> and <footer> tags so the theme doesn’t have to be a table. It will be definitely simpler to work with.

How you add Signature at bottom in your File?

Cheers Lubos. So not a completely different philosophy, but a bit of a different perspective. I can’t be convinced that table-based layout is a good idea for all the reasons discussed, and I do hope that the internal CSS will be supported again sometime soon.

Use an online tool (like this one) to convert your image to Base64 encoded text. Then put that in your HTML like this:

<img id="signature" src="data:image/png;base64,encoded_text_for_PNG_image_goes_here">

1 Like

Search the forum. A straightforward method using custom fields was provided earlier.

@lubos, the date found in the fields array, appears to be a string rather than an actual date object. As such, it doesn’t respond to Liquid’s date filter. Is there a way to access the date object instead?

At the moment I have to access it with either:


or something like this:

{% for field in fields %}
	{% if field.label == 'Invoice date' %}
	<p>{{ field.text }}</p>
	{% endif %}
{% endfor %}

(I don’t want to change the date format in Manager preferences—just override it in one place on the invoice.)

1 Like

This is how I have always done it, because I like to send invoices from within the Mail app. I find it handy to choose ‘Mail PDF’ from Apple’s print window.

However, it no longer works. When you choose ‘Print’, the PDF looks nothing like Manager’s preview—everything is broken. This would be a disaster for me if the print behaviour can’t be changed, having finally got my invoice theme to where I’m happy with it. Please tell me how I can print the invoice as it appears in Manager (not use Manager’s inbuilt PDF generator.)

Edit: Sorry, I made a beginners mistake. My CSS had the media set to “screen” so it wasn’t being used when going to print. Removing that fixed the problem.