News:

Bored?  Looking to kill some time?  Want to chat with other SMF users?  Join us in IRC chat or Discord

Main Menu

Customising function constructPageIndex (nasty evil stuffz)

Started by Antechinus, July 03, 2014, 09:56:07 PM

Previous topic - Next topic

Biology Forums

Quote from: Antechinus on January 09, 2015, 08:02:47 PM
Ay up. Was just going over this again and had a brainwave, which I should have thought of before. Pseudos. Ditch all the txt strings and just use pseudos. Easy to style, unlimited choice of content, and no translation issues. D'oh.

* Antechinus is using pseudos now, just in case you were wondering.

Could you provide us examples of the fruit of your labour?

Antechinus

#21
Ok. Desktop and mobile, with dots and expanded.

The shiny indicators for the next/previous buttons are done with CSS borders on :before pseudo elements. The actual HTML coming from Subs.php is just a basic non-breaking space. The default text that says "Pages:" before the list is still there, but now has a defined class so it can be hidden by display: none; if you don't want it (I obviously don't).

This also applies to the tiny <<  >> things on the message index. Basically, all ugly stuff in Sources is replaced with non-breaking spaces, and all visible content can be styled up with your choice of CSS. Everything has the ruling class of .navPages, with everything apart from the basic page links also having an auxiliary class for easy targeting.

None of this requires template edits now either. I dropped the idea of using an unordered list (too much PITA for not enough benefit) so all of this will just drop straight into default templates markup via $context['page_index']. I'm defo going to package this soon. Just need to do a bit more through checking for odd bits I may have missed. :)

ETA: By the way, with these buttons in action I think it's best to set admin to show only one contiguous page. That way it all fits on a phone, and with the ... buttons, plus the first and last page always displaying anyway, there's not really any need to display any more than one contiguous page. It's just a waste of space and will only annoy mobile users.

Antechinus

Oh yeah, code. Sources goes like this. You can see the space character that gets sprintf'd in with the rest.

// Show 'Prev'
if ($start > ($num_per_page - 1))
$pageindex = sprintf($base_link, $start - $num_per_page, '&nbsp;', ' previous_page');



And the CSS goes like this:

.previous_page, .next_page {
text-indent: 100%;
overflow: hidden;
padding: 2px 0 4px 0;
width: 33px;
}
.previous_page:before, .next_page:before {
content: "";
position: relative;
display: inline-block;
left: -26px;
vertical-align: middle;
height: 0;
margin: -1px 4px 1px 4px;
border-right: 12px solid #444;
border-top: 6px solid transparent;
border-bottom: 6px solid transparent;
}
.next_page:before {
border-right: none;
border-left: 12px solid #444;
}
.previous_page:hover:before {
border-right: 12px solid #b47a0b;
}
.next_page:hover:before {
border-left: 12px solid #b47a0b;
}


That can actually be simplified slightly as I was using some of the fancy positioning to hide the text strings, just before I thought of using a space character instead. The final version will knock a few lines off that. The space character is useful for the pseudos though, since it allows them to be vertically aligned without any bother.

Antechinus

Hey I have a general feedback/discussion question. This may be better in the Customization Development board now but I'm not fussed.

I have the code sorted so it's bug-free on all pages, but what I'm wondering is about the old default text that says "Pages: " in front of the list of numbers. I've never liked this text and usually remove it. I regard it as a waste of space since I expect everyone knows what the list of numbers is for (standard web practice for years and all that).

With the mod package, to make this text optional/stylable I have to do a find/replace on 35 hits in 12 files, which is ok. They can all be set to skip on error since they're not critical. The question is what to replace the default code with. At the moment I have stripped Subs.php so it doesn't generate content for the "Pages: " stuff (because I don't want it).

With the actual mod there are then two options:

1/ I can set the mod to replace it in the template with <span class="navPages page_text"> etc, if the consensus is that it would be better to keep the old default blurb while making it targetable via CSS, or

2/ I can just set the mod to remove the old stuff without bothering to replace it. This will obviously simplify the CSS for some people, if they don't want it displayed, and will also simplify the markup.

I think 2/ makes more sense, but am open to doing 1/ if there's enough call for it. :)

Arantor

No, there are more than 2 options.

3. Change the value of $txt['pages'] from inside constructPageIndex. The language string will have been loaded by then and can safely be changed by constructPageIndex in any circumstance I can think of.

4. Use the buffer hook to add a buffer and do a replacement on $txt['pages'] from after it has been displayed. Several mods now exist demonstrating this concept.

Antechinus

Ah, but you're forgetting a very nasty little piece of 2.0.x markup evil. The actual text is called from languages, but the colon and the space after it are not. They, for some obscure reason, are hard coded into the templates. Therefore, if you do not wish to have "Pages: " displayed, you will be left with a colon and a space in front of your page index if you try to jigger it via languages/hooks. The colon and space are also impossible to target via CSS, since they are not elements and cannot be assigned to a class.

IOW, template hacks FTW.

Arantor

So that rules 3 out. That most certainly does not rule 4 out. You just target $txt['pages'] plus the colon and space.


Arantor

Sure you want to learn how hooks work? Because this is where it starts to get crazy evil voodoo. Consider, essentially, that what I'm about to show you is 'the *entire* page HTML is going to get shoved into a PHP variable that you can abuse with str_replace for fun and profit.

Antechinus

Ok. Well TBH, that sounds like it can go do evil things with syphilitic goats for all I care. I'm thinking that if there's not an overwhelming desire for people to keep that frigging text, they'd be better off with clean markup. These are very minor template edits that, in practice, will not cause any problem. If someone has already edited their template there, which is not going to be very common, the mod will just skip.

Arantor

Then for your maintenance purposes you're probably best doing that. I'm just pointing out that there are alternatives that do not require vast edits - and if it were me, I would be quite comfortable adding a buffer and doing it that way. But I realise this is a specialised approach and not suited to everyone.

Antechinus

Yes but they're not vast edits. They're only tiny ones. It just so happens that there are 35 of them, but the vast majority of those are in templates that nobody apart from me is ever nuts enough to edit.

And FWIW, it'll still play nicely with your page dropdown mod. I've checked. Chalky would spew if it didn't. :D

Arantor


Antechinus

I didn't even know about it until today, but making it look smooth with what I'm planning is a piece of cake anyway. It's not a bad idea, although I'd never thought of it, and am not sure I'd ever want it once I have next/previous buttons running, but there's certainly no harm in it.

Antechinus

Ok, after sleeping on it I've decided to go with the clean solution: I'll just exterminate the "Pages: " BS. If anyone then throws a tizzy about its absence, I'll explain exactly how they can write their own mod to add it back in, while still keeping full styling flexibility and integrating with my mod, and tell them to go for it. :)

onepiece

If it's for a theme, I would suggest the following change to index.template.php file of your theme:

Code (Find) Select
$settings['require_theme_strings'] = false;
}


Code (Replace) Select
$settings['require_theme_strings'] = false;

$settings['output_buffers'] = 'strip_pages_label';
}

function strip_pages_label($buffer)
{
global $txt;

$buffer = str_replace($txt['pages'] . ': ', '', $buffer);

return $buffer;
}


The code to find is basically the end of 'template_init' function. You just define the function to use to modify the output using the $settings['output_buffers'] option. The function could be improved to use regular expressions not to strip unwanted matches too.

Antechinus

Yeah I want it as a mod though, because I want to rewrite the Subs.php output anyway. So I'm just going to hit the templates with edits. Like I said earlier, doesn't matter if some of them skip, but chances are nobody will have edited them anyway. It's very minor and obscure stuff.

Arantor

I don't understand why $txt['pages'] plus the extra markup wasn't part of constructPageIndex in the first place, when it never gets used without it as far as I remember.

onepiece

You could just do this in Subs.php then:

Code (Find) Select
return $pageindex;
}


Code (Replace) Select
add_integration_function('integrate_buffer', 'strip_pages_label', false);

return $pageindex;
}

function strip_pages_label($buffer)
{
global $txt;

$buffer = str_replace($txt['pages'] . ': ', '', $buffer);

return $buffer;
}


Sorry, it sounds painful to make a package for all those edits, so I couldn't resist. You could probably even avoid making changes to source files at all by making changes to the output using regular expressions.

Antechinus

Because they were bonkers in them days. Still are. :D

Anyway it'll get used without the bastard by the time I'm done with it. ;)

And no, it's not painful at all. I'm a themer. I make template edits all over the place, including complete markup and PHP rebuilds, just for fun. This is nothing.

Advertisement: