interception points that are actual events and others, like rendering of entries or content.

And I appreciate that and I also made it very clear that if I did something specific in the Admin the interceptor will not fire, I never said it was an interceptor, you have made that conclusion.

If you know it that well then that post will give you the clue, and from what I have seen this setting has been around for months.

Now as it is a bug, I have created a ticket for it.

And after looking at the code, it is an actual interceptor point as well.

So happens it is of the same name, of the interceptor that I am having issues with.

I looked at your bug report.

“When using the Before A Blog Entry for global HTML I have issues where the interceptor for cbui_preEntryDisplay will not fire, and now I have it the other way around. Where the interceptor will fire but the cbui_preEntryDisplay is not added to the output.”

In my example I had already created an interceptor in the example user defined module “Hello” that responds to the cbui_preEntryDisplay interception point. Based on the bug report, I now added HTML to the “Before A Blog Entry” for global HTML. I then tested as in my example by going to an entry. I see the “Before A Blog Entry” HTML that I entered. Then I see the dump from my custom interceptor responding to to the cbui_preEntryDisplay interception point. Then I see the entry content. It appears to be working. Therefore, the bug you are encountering may be caused by the specific content that is being entered into the “Before A Blog Entry” for global HTML. The bug report doesn’t say what that content was. Can you share the content you were using in the “Before A Blog Entry” global HTML?

It can be anything…

I have tried

This is a test

and

.. with some style to restyle certain elements

I have also tried

#now()#

The thing is it just will not work, to give you an example I am reformatting some styles that need to be adjusted. If I remove the coded interceptor the style is applied, and as you can expect it is found in the view source. However as soon as I put the coded interceptor back in the style is not applied and is not found in the view source.

In my “Before A Blog Entry” global HTML I have entered:

This will appear before every blog entry.

.post{color: red;}

I have included a screen shot of when I view an entry. It has the “This will appear before every blog entry” in bold. Then it shows the arguments dump I did from the interceptor responding to the cbui_preEventDisplay interception point. Then it shows the entry body and it is in red using the updated style I had in the “Before A Blog Entry” global HTML.

You mentioned something about it being the same name as the interception point. What exactly was the same name as the interception point? Can you supply the name and code you used in the interceptor?

Michael

Michael the section in the Admin to enter this uses the same interceptor point as my code, whic is what we have been talking about.

Ok, I don’t know why it works for you. But I can tell you I have the latest release and it does not work for me.

Yes. I understand that the GlobalHTML interceptor responds to the same interception points.

I also have the latest code from GitHub, modified about 6 hours ago. I believe it is not working for you. However, to assist or fix, the error has to be duplicated. The best way to duplicate the error is to use the same code that is producing the error or be provided a sample that exhibits the bug. That is why I keep asking for samples of the code you are using. I am sure Luis will ask for the same thing if he cannot duplicate. It appears as if there may be a conflict between your interceptor and the GlobalHTML interceptor that is breaking the chain.

Ok your example does work for me, so I decided to back track a little and found the cause.

addAssets();
addJS();

That is what I am doing in my interceptor, this is being outputted every time. However if you then add the part in the Admin section then that part will not be called.

I need to do it this way because these are loading styles and JS that are going to be added to the section of the template. So now I know what it is, now I just need to know why.

So my entire method looks like this

public void function cbui_preEntryDisplay(event, interceptData) {
addAssets(event, interceptData);
addJS(event, interceptData);
}

Now I do notice that Luis has got appendBuffer, but that is not a solution here because $htmlHead() will not work with that. Which is in the addJS() section but I even commented that out, and it still refuse to do the Admin entered bit.

Great! Glad you found the cause. In addition, seeing your interceptor method gives me something to go on. Let me see if I can duplicate the error now. Basically, your ultimate goal is to get the styles you enter in the “Before A Blog Entry” to be output in the head section, correct? The one issue I see is that the GlobalHTML interceptor will also still respond to the interception and will still appendToBuffer() at the point of the announcement. This would cause the code to exist in the body as well as the head section. The GlobalHTML interceptor would have to be disabled to prevent it. However, that is not probably desirable. A different approach may be needed.

Michael

No, I really don’t care about the “Before Blog Entry” for what I am working on. But for testing and making sure it works, I tested it with something in there, to make sure it all works still.

Which is when I started having these issues.

No my stuff is required to go in the head section of the output, which is why I did what I did.

OK. Here is what I did and it works to accomplish your goal.

  1. Removed the styles from the “Before An Entry Display” global HTML since we don’t want it in the body.

  2. Added and entry under “Content : Custom HTML”

name = “cbui_preEntryDisplay”
slug=“cbuipreentrydisplay”
content:

.post{color: red;}

I had to click the source tab to paste it since it was already HTML

  1. Then I changed my EntryInterceptor to this:

component {

property name=“cbhelper” inject=“id:CBHelper@cb”;

void function configure(){}

void function cbui_preEntryDisplay(event,struct interceptData){

$htmlhead(cbhelper.customHTML(“cbuipreentrydisplay”));

}

}

This correctly added the styles to the head section. Let me know if this is what you are after.

Michael

No it is not.

Let’s take a step backwards, my module actually works. The problem is when someone enters the information into the section that I mentioned, this causes problems. I am able to duplicate both problems that I am having.

The problem is that if someone else wants to use this module, I can’t dictate to them not to use such and such of a feature because it means my module will not work if they do. The point is that my module does use that particular interception point, and it won’t work based on what I am trying to achieve with the module.

Forget about me and my module, think about how others may end up using this module. And as it stands my module is not compatible with that section or any other section of content that is changeable from the admin if I hook into those interceptors and decide to do things like what I am with adding assets and JS.

Is that a bit clearer now?

A user should be able to still add to the “Before An Entry Display”. However, when I tried with my last sample. It did fail. I got the styles in the head section but not the output from the “Before An Entry Display”. Great! I now have a working replica of what you are describing. I also now realize the cause of the issue. Any functions using the htmlhead clears the current buffer. If I modify my interceptor to this it works:

component {

property name=“cbhelper” inject=“id:CBHelper@cb”;

void function configure(){}

void function cbui_preEntryDisplay(event,struct interceptData){

// Save the current buffer contents

var buffer = getBufferString();

$htmlhead(cbhelper.customHTML(“cbuipreentrydisplay”));

appendToBuffer(buffer);

}

}

And it is not just the $htmlhead() either unless this uses it too

addAsset();

btw thanks for being so patient here, you can understand I have spent a great deal on this and I am tired at the moment.

Yes. The underlying methods behind addAsset also use $htmlhead. We know the cause and a workaround. Now, we can look further into a fix, but not tonight, I am going to sleep! :slight_smile: