Are there any obscure perils of custom EVENT identifiers?.

[Sean Moran]

Hello again all and may you enjoy a happy start to this new week. I have started work on building a new style for my 2018 forum, using phpBB version 3.1.10 in conjunction with all fifty-four(54) language packs and a good helping of fifteen(15) fantastic extensions. I have identified one quirky conflict of interest, ironically concerning two(2) of HiFiKabin's excellent extensions, and I have read quite a bit of the tutorial on extensions herein today.

I contemplated posting this thread somewhere in the Extensions section, but as my concern relates to EVENT indentifiers, which are part of the main phpBB code, I decided on the general support section. Please feel free to move this if I have zagged when I should have zigged.

I will include a screenshot of the current layout of my unfinished Board Index page below, to provide a visual example of what I have done so far. In summary, my navbar_header is now directly above the navbar_footer, at the bottom of the page, and the Search textbox is contained in the navbar_header, (using HiFiKabin's extension).

Whether it is wise to position the navbar_header at the bottom of the index page depends on whether one construes the name 'navbar_header' as the navbar in the document header, or the header of the navbar. I have chosen the latter, and like my navbars down at the bottom, to give prominent attention to the forums.

Back up there in the overall_header, I have added the Google Translate div, (using HiFIKabin's translate extension for the <script> parts), and most importantly for this thread, installed HiFiKabin's Moon Phases extension, and this is where it gets complicated.

Because the Search Box is now down the bottom in the heaver of the navbar, it seems rather silly to retain the <EVENT overall_header_searchbox_before> tag in the overall_header. The searchbox is not there anymore. So, I have made a few changes to the overall_header.html file, and duplicated HiFiKabin's template/event/overall_header_searchbox_before.html event listener, and renamed it overall_header_moonphase.html. There are both in that directory now, although the original is just there because it doesn't work if I rename it to take it out.

Here is the code which I have currently in the overall_header.html file to position the image of the Moon at the right of the overall_header:

Code: Select all

   <!-- nonEVENT overall_header_searchbox_before -->
   <!-- EVENT overall_header_moonphase -->

I have made my own EVENT, with its own identifier, and added that to the overall_header.html template.

What I would like to ask those who know this more recent version of phpBB is, are there any pitfalls or perils which I should consider before I go ahead and add the occasional custom EVENT identifier to any other extensions, providing that I remember what I have changed, so that any new extensions which maybe added in the future will still find their way onto the overall_header, navbar_header or overall_footer in the places where I would like them to render?

I think it will be okay, but I am not really conversant with the technical details of extensions. I have always thought of Symfony as something developed by Lotus 1-2-3 in the last century. Please let me know if there are any peculiar results to be expected by adding custom EVENT identifiers to the main phpBB templates, apart from the possibility of needing to adjust the template/event files of other extensions. I am aware of that one.

Here is the Board Index screenshot in its current unfinished form so far, to better illustrate the preferred layout for the navbar/s. Thank you for reading my excessive explanation.

[david63]

There seems little point in removing a core event and replacing it with a custom event in the same place - you are achieving nothing other than making work for yourself when you update either the core files or the extension.

As to using custom events then there is nothing wrong in doing so but I would not recommend removing core events as you run the risk of extensions not working, and remember that you will need to make all these changes to each style that you have installed (if you have more than one).

Whether it is wise to position the navbar_header at the bottom of the index page depends on whether one construes the name 'navbar_header' as the navbar in the document header, or the header of the navbar. I have chosen the latter, and like my navbars down at the bottom, to give prominent attention to the forums.

Obviously you can move things to wherever you want but moving the navbar_header to the bottom looks strange and turns the "Quick links" int "Slow links"

One thing that I would say is that when making the types of changes that you are doing you should be creating a "child" style - that way you will save yourself a lot of problems when you update.

[Sean Moran]

<SOLVED>

Hello David and thank you once again for your reply. You have been there for me for every single support thread I have posted in these past few days, so I do believe that should be commended first of all, before I rant on again. Thank you.

It seems that there is nothing too obscure to worry about here, and I have considered the extra work involved in adding any new extensions should the need arise. I don't think that it will slow the whole process down by leaving those nonEVENTS there in the source code, and it is probably only this one event for the search box in the header which I will be relocating to the navbar_header, (down there above the navbar_footer - yes, I realise I am a little pedantic to insist on adj. before n. so I have probably misinterpreted the meaning of navbar_header

On the Quick Links, it is certainly going to be necessary to add some of the most important anchors back up into that overall_header before opening day, and there might eventuate a case where I will split the various anchors on the navbar_header and move most to the footer, and then return the navbar_header to the space beneath the overall_header once again, when I can develop a complementary background to go with the bg_header and bg_list graphics.

The Quick Links is a top contender to get a place at the top of the index page, as is that Board Index with the listing of the subforum tree as well, as these are very often used in navigation.

Other anchors such as search, I ... maybe youire right, and I should put the navbar_header back where it was and move the anchors I don't want up there down to the footer.

I am just glad to read that it is not going to send the extensions server into conniptions if I include a custom EVENT identifier when required.

I should also mention that the original prosilver style is right where it was on installation, (with all fifteen(15) extensions installed), and my custom orbitalo2_std style inherits from prosilver, although it is built on a copy of the entire prosilver directory with the style.cfg changed, at the beginning.

Thanks again for being the most tolerant expert on phpBB of my obtuse diction.

[Mick]

I have started work on building a new style for my 2018 forum, using phpBB version 3.1.10

Why 3.1, it will be EOL by 2018?

Also, there are no threads in phpBB, they're topics.

[Sean Moran]

Hopefully by 2018, the other twenty-eight(28) language packs which turn 3.2.0 to snow will have been updated so that they will habitate the latest version as peacefully as they do on 3.1.10, but I am not holding my breath, Mick. It looks as though I will have to use the Google translate function to add the required parts when I get the time, and I don't quite have that much spare time allocated over the next six(6) months unless things go very smoothly with all the other jobs. When 3.2.1 is stable, maybe it wil be time to upgrade ?

I understand those who get pedantic over semantics, because I am quite old-fashioned myself, and from where I write, phpBB is a topic, and so I call this a thread. To me, the topic of this entire forum is phpBB. Sorry if I confused you, sir.

[AmigoJack]

the other twenty-eight(28) language packs

Don't put too much hope into having all those languages: they're only for the board controls, while your content (in posts) will never be translated. Also thru the years I've spotted a couple of mistakes - just because a language pack is available doesn't mean it's flawless.

I call this a thread

The difference is a technical one: in threads you can answer to each post individually, which results in a tree-like discussion. In topics you can only reply in general, which results in a flat stream-like discussion.