Think I am having this problem. Has anyone been able to make this work recently?

I am not allowed to purchase plugins for a big "On-Prem" instance of Confluence.  Why would Atlassian recommend (or allow) a 3rd party plugin (especially at an additional cost) be the fix to their bug???  

Here is my scenario:

1) I am on an "On-Prem" instance of Confluence. The URL is something like:

    (Note this on machine 1)

    https://machine1.big.researchdomain.net/display/myproject/

2) I have a page on this Confluence instance called "InformationPage" so the full URL is:

    (Note this on machine 1)

    https://machine1.big.researchdomain.net/display/myproject/InformationPage

3) Also on the network is separate web server hosting a separate webpage (under another co-teams control):

    (Note this on machine 2)

    https://machine2.big.researchdomain.net/different-page-I-want-to-display-in-confluence.html

4) On this "different-page-I-want-to-display-in-confluence.html" page, there are some referenced URL's:

    (Note they are all also hosted on machine 2 - the same separate web server under another co-teams control)

    https://machine2.big.researchdomain.net/infopageA.html

    https://machine2.big.researchdomain.net/infopageB.html

    https://machine2.big.researchdomain.net/infopageC.html

5) I was able to get the "HTML Macro" and the "HTML Include Macro" working

6) I was able to get this URL of the other server (machine 2 - https://machine2.big.researchdomain.net ) added to the allowlist of trusted URLs in Confluence (again on machine 1).

7) When I add a "HTML Macro" OR "HTML Include Macro" to my Confluence page it works! (but wait for it)

    (again my Confluence page on machine 1)

    https://machine1.big.researchdomain.net/display/myproject/InformationPage

    (the page from machine 2... that is now being displayed on my Confluence page on machine 1)

    https://machine2.big.researchdomain.net/different-page-I-want-to-display-in-confluence.html

    (now all the URL's on that page are being rewritten)
    (Note they are all pointing to machine 1 and not machine 2 like they are supposed to... see #4 above)

    https://machine1.big.researchdomain.net/infopageA.html

    https://machine1.big.researchdomain.net/infopageB.html

    https://machine1.big.researchdomain.net/infopageC.html

Lastly, this is a single very simple example of a much bigger problem for me. My actual problems are more complicated (but same principle). Other problems include:

• pages that call other dynamic javascripts and web service URLs to build pages that when displayed via Confluence do not work due to rewriting.
• pages that display, but the data that feeds the page is via another service call (so no data ever arrives).
• pages that display, but the formatting (CSS, etc.) that is needed is never called therefore the page is not readable (as it never formatted).

HELP!!!!

Seconding... now that Portfolio is actually usable, I can't post a link to it in Confluence, I guess because it's a relative link.  Yes, I've had the admin turn on the macro and white list the site.

Wow... get your apps to talk to each other.

>  mean does Atlassian reject ANY feature request, that already provided by ANY 3rd party software complient with Atlassian product?

Historically (and I mean many years ago) the theory was no, Atlassian would not stomp over an existing app with a duplicate of the functionality, and if they wanted it badly enough (flash workflow editor, Valiantys SLA), then they'd buy the app.  Of late, it seems like there has been a sea change, where even a pre-existing non-trivial solution such as Enterprise Mail Queue for Jira that's been around for 5years providing Email Digesting functionality in Jira as a solution to JRA-1369 suddenly becomes the target of a new feature Email Digesting coming soon in Jira8.  Nobody contact us!  Apparently, after we reached out,, the person leading that feature saw no conflict between EMQ Email Digester and Jira Email Digesting.  I can't tell if this is a deliberate change in policy or an exceptionally poorly handled fit-gap analysis by Atlassian staff.

CHTMLIR was written to solve my own problems, integrating local net web server CGI output, it was great!   Commercially, sure, its not a killer app, its a point solution, don't be grumpy, be happy someone bothered to solve a problem, support them even!  Maybe if you have a related problem such a smaller company will be agile enough to actually do something to help you.

Is an issue resolution a result of official Atlassian policy?

I mean does Atlassian reject ANY feature request, that already provided by ANY 3rd party software complient with Atlassian product?

If it is not I think it would be nice enough to motivate your rejection.

Sorry, "Jambit Sysadmin" is right. So you want to tell us that we have to buy something and this is the reason why you don't do anything. Stupid, unpolite and awful!

Considering that the macro you linked to costs money while this one is part of Confluence, I think closing this with WontFix is not acceptable.

As this functionality is now provided by an add-on made and maintained by The Plugin People, I'm going to close this issue as Won't Fix.

Hi Andy,

Is it possible to import the html permanently to the confluence? . I was hoping for something that would import the html permanently into the confluence. This one seems to do the import on every access, which is very nice but I need to have the document updated by many people in the organization. The Confluence provides a way to tag and track changes that are not available in straight html. Could you please let me know if it is possible.

Thanks & Regards,
Rambabu

Its been submitted to Atlassian today for review, largely unchanged since last submitted a year ago - have been busy !

Hi Andy,

Is this plugin available now to confluence 4.3.6? If available please provide me the plugin.

Regards,
Rambabu

FYI, that plugin is coming to a C4.2.x via Marketplace real soon now.

The Plugin provided here https://studio.plugins.atlassian.com/wiki/display/CHTML/HTML+Include+Replace does not work on latest confluence. Come on, that can not be to hard to fix that in Confluence itself? Would be really nice to have this.

Here is another issue with HTML Include Macro.
CSP-71983

Link to attachment fails using HTML Include macro.
On the very page that has attached files links are working normally. But if the page with links to its attachments Include using HTML Include macro into other page - when viewing links appear to be broken.

This issue raised only with Advanced Macro plugin version 2.0.30
Now I rolled back to Advanced Macro plugin version 2.0.28 and links to attachments in included page are working normally.

Big thanks to Andy for helping me to get this working on our confluence installation and updating it to work with our website's formatting.

I would strongly encourage this change to get rolled into the standard

macro. The current macro simply doesn't work on 50% of websites.

-Will

Final bugfix. , SVN commit is https://svn.atlassian.com/svn/public/contrib/confluence/html-include-replace Mat? Care to review/comment?

Also created a plugin page: http://confluence.atlassian.com/display/CONFEXT/HTML+Include+Replace

Final bugfix for anyone interested

Updated version of the plugin that uses a more advanced regexp approach to fixing the problem for links like:

<A HREF="someplace/xyz.com">

This revision uses the relative path of the containing folder of the resource that was loaded (theoretically supporting relative paths buried in a given context/sub-path).

FYI, one of the two regexps used (this is for absolute url matches):

(href|action|location|src|script|object|data|codebase|archive|longdesc|cite|ismap|usemap|poster)=(['|\"])(/|[A-Z|0-9](?![A-Z]*:))

Pre-existing protocol links ( e.g. ftp: https: mailto: file: outlook: \\uncserver\place ) are left untouched.

I've added a bunch of unit tests which seem to show it working without side-effects...

No word from Atlassian; following advice looks like I have to create project for this first off and invite reviewers. I'll do this and see if I get a bite, if not, I'll try to set up a plugin page and leave as is.

Thanks for that Andy, this might help expedite the resolution of this issue.

{html-include-replace:url=http://server|remove1=noautolink|rewriteServerUrl=true} 

remove1..99999, tags marked like this, ie noautolink will be stripped from the file, helps during some html cleansing.

I would like to make use of the whitelisting feature in the atlassian html plugin but cannot yet. I just mailed an atlassian developer to see if there is any possibility of getting the include-replace code I've written bundled. For interest if anyone wants to play with the plugin in its non-whitelisted form, I'll attach it here.

I have a working 'include-and-replace' macro to fix the relative URL link failure problem, Ive cross posted feature requests to HTML-15 and CONF-13365.

If there is interest I'll startup a plugin page to host it in the interim....

You might want to look at the HTML Plugin as it's more robust overall I believe.

http://confluence.atlassian.com/display/CONFEXT/HTML+Plugin

I'd vote on this, but I'm not allowed to, since I filed the original bug.

We use Confluence as our in-house knowledge base, and therefore I trust my users enough to enable this macro by default. We had a central web site before where we used to keep a lot of our information, and it used relative links throughout. Rather than manually move all of these pages from our old web site to the current wiki (a very time-consuming process), i tried to use html-include to include the main page of the other web site. But, then I got an error when I clicked on any of the links in the old web site.

I've been asked to give a status update on this bug.

While this is a fairly critical bug with the HTML-include macro, this macro is disabled by default. Given there's zero votes and no comments other than Atlassian's, it isn't currently scheduled. If you're worried about this bug, please note your problem and vote for this issue. It will help us prioritise it amongst the other outstanding bugs we have to fix.