Categories: bane or boon

Categories: bane or boon, a forum discussion on Jojo CMS. Join us for more discussions on Categories: bane or boon on our Plugin Announcements forum.

Back to Forum Index : Back to Plugin Announcements Page << [1] [2]  RSS
tom

Developer

tom

24 Aug 2010
Posts: 379

no, i use them all the time, i just ended up re-naming them so they could be consistent across all plugins including non-category ones and to get way from the idea of categories which seems to confuse people and reference the page instead which is what they are actually doing in any case.

so they are now just called pagetitle and pageurl and embedded along with the rest of the article data so they don't need to be accessed separately

they can be used either in the title/link for each article (if using a mixed collection across multiple categories - like in the elsewhere.co.nz sidebar)

eg
{foreach $articles a }
&gt; <a href='{$a.pageurl}'>{$a.pagetitle}</a>&gt; <a href='{$a.url}'>{$a.title}</a>
{/foreach}

or at the end (like 'see all news') by pulling them out of the first entry
&gt; <a href='{$articles[0].pageurl}'>See all {$articles[0].pagetitle}</a>

Numcomments was indeed broken by the latest changes. Have commited a fix today. (and one for comment subscriptions, which were also broken).


Rick Rick

24 Aug 2010
Posts: 336

You, Tom, are a legend. Thanks for helping me out so quickly.
tom

Developer

tom

24 Aug 2010
Posts: 379

no problem. happy to see it being tested. have you tried the sub-category/index/parent stuff - does it work like you were expecting?
Rick Rick

24 Aug 2010
Posts: 336

I noticed it, but haven't even looked into what it does yet sorry. I was making sure everything I was using was working first before doing a push to my server.

I'll check it out over the next few days though, I'm very busy at the moment and just lost 4 days to food poisoning.

What I did notice though, but I didn't have time to try it again, is that when I created a new article category it automatically created the page, but the page had no status.

I miss being able to edit the category (page) name from the article categories section, but there's no doubt that it all fits together better now.

[edit] I just checked it again and the page status is "Hidden" on new pages added from the Article Categories section. I must've hit something wrong last night.

Another thing I thought about is that while I like the new way article RSS urls are done (just appended to the category url instead of a new page made)... what about sites that use external feed services which insert ads etc? Anyone not wanting to have the ads in their feed can just guess the feed address on the site.
tom

Developer

tom

24 Aug 2010
Posts: 379

The category to page function is a bit clunky - i only put in in as a fix for orphaned articles (where their original category page has been deleted), so the page it generates is hidden and titled 'Orphans', but at least maintains the correct categoryid/pageid relationship.

The expected behaviour is to make new categories from Edit Page, where the whole thing is handled more cleanly (and to avoid duplicating page information in the category table).

The Rss thing.. - i'm guessing it just needs a check at the getFeed stage to see if an externalurl has been set for that category (as per Searchmaters additions), and redirect to that?
Rick Rick

24 Aug 2010
Posts: 336

I had thought I'd break it by adding pages manually instead of doing it through the categories section. That's good, so it was just me using it wrong.

With the RSS thing I thought about a redirect, but then how would the external service get the feed from the site initially? Or do they provide the IPs for their scrapers etc for whitelisting? I've never used such services but I they came to mind when I saw the changes.
tom

Developer

tom

24 Aug 2010
Posts: 379

I've committed a tweak for redirecting the rss url to the external link, but you're right - that won't work.. :p

maybe if it has an additional check to see if the referrer is the same as the link? Hopefully Searchmasters (who uses external feeds more than I do) can shed some light on it..?
searchmaster

24 Aug 2010
Posts: 19

The core rss feed HAS to work, there is not allowed to have a redirect as you describe.

The system works as follows:
you set up a feedburner link. It gets the rss from the normal jojo rss feed (thats why you can't redirect it)
You then show that feedburner link on your pages

or you set up a mybrand rss feed like http://rss2.searchmasters.co.nz/Searchmasters - via cnames in your hosting, and feedburner (account link). Feedburner gets the rss from your normal jojo rss link.

Because you have to set up external rss feeds, its easier that any changes to categories rss feeds etc and their resulting external rss url's be manual redirects.
Rick Rick

24 Aug 2010
Posts: 336

Yes, that's all sounding right, but what we were meaning with redirects is trying to stop visitors from subscribing directly to the websites rss feeds by knowing the address. We were looking for a way to redirect visitors who loaded the site's rss feed to the external one, but still let the external provider load the site's rss feed.

Eg if I try to load your the feed straight off your site then I get redirected to the Feedburner version, but when Feedburner loads the feed off your site, they get the actual feed. Does Feedburner tell you what IPs they'll be scraping from or something so we can redirect anyone loading the site's feed that isn't Feedburner TO Feedburner?

Come to think of it I could just look it up...

Found it... Feedburner's scraper uses a "Feedburner" useragent. However that doesn't help with all the other similar services. We could add a select box to the category to choose which external service, then perform different checks (useragent, ip, etc) as required for the particular service in use I guess.
searchmaster

24 Aug 2010
Posts: 19

I find that when you start to get too tricky, things can break easily. I would rather lose tracking of a few ultra smart people that guess the backend rss feed url than potentially break things for all my many subscribers if user agents etc change.

We tried to check for googlebot, using the phonehome via ip address official method (see below), only to find that there were some exceptions and got a website delisted from Google for a while. We had been getting people scraping client websites, and if they had noindex nofollow meta tags on them we were able to stop the damage that was being done to rankings.

Its safer keeping things simple.

per the jojo_simplecloak plugin:

A Jojo implementation of the SimpleCloak script for WordPress found at http://www.seoegghead.com/blog/simplecloak-v2-php-implementation/

This is not a trivial change to your website, so make sure you read and understand exactly what is being changed.

This plugin adds noindex,nofollow meta tags to every page of the website, unless the visitor is a known bot such as Googlebot.
The decision as to whether a visitor is Googlebot is made by doing a forward and reverse DNS lookup on the visitor IP.

Please read the following links for more information...

http://www.seofaststart.com/blog/google-proxy-hacking
http://googlewebmastercentral.blogspot.com/2006/09/how-to-verify-googlebot.html
http://www.seoegghead.com/blog/seo/how-to-guide-prevent-google-proxy-hacking-p210.html
http://www.seoegghead.com/blog/simplecloak-v2-php-implementation/

Big thanks to Dan Theis and Jaimie Sirovich for the scripts, and the writeup.
tom

Developer

tom

24 Aug 2010
Posts: 379

nice post, thanks.

now, for possible unpleasantness..
I've spent a chunk of time recently (one of the exciting by-products of un/self-employment) on trying to understand the language / lang_country code in Jojo, and it's time for a cleanup.

As far as I can tell the language table doesn't do much anymore as far as most plugins are concerned - it's just there to set the html language in the xml header, or to choose the search language (my feeling about search is that it should still be searching the actual html language, not just whatever lang/country section the page is in). The rest of its old functionality (setting root & home) has been superceded by lang_country and is now redundant and should go, as leaving it there introduces unnecessary confusion.

This may well break things - any old plugin code that is still operating on the old model - but as far as I can see, this is the easiest way to find out where that is still occurring and to fix it.

Ideally, in the end, it should mean that all plugins use the same getMultiLangString functionality to work out any sub-site url prefix required which will result in not just more consistent behaviour, but mean that the transition to true multi-site setups (as in Jojo2) will be a lot easier to implement.

What would be cleanest is to hide the lang_country field altogether in 'edit pages' and have it as a hidden field that gets set based on the root settings in lang_country (it seems redundant to expect clients/anyone to set this field specifically when setting up new pages when they are already setting up the tree into which the page is going) - but I haven't gone that far with it yet.

I'm still testing all this (to the extent that I can on a limited number of sites/plugins) before committing, but this is a heads-up and thoughts on the matter would be most welcome.

searchmaster

25 Aug 2010
Posts: 19

The concepts need to first be made clear:

You should be able to have subsites based on either language, or alternately by country.
ie /fr/ for french language, /es/ for spanish etc. But also have /fr/ for france, and /es/ for spain.

But then be able to have /ar/ for argentina that is in spanish, but also have pages in /ar/ that are in english

So html head needs to be able to be set as a language independently of the country.

A country needs to be set for the url, then on a page level the language needs to be able to be set if it is different from the default for that country.

Yes, you could have all the different language settings on a page level - left/right,language code, local and english name. But that is rather anti database theory of setting things in once place and being able to reuse them.

If you set the language settings on the country page, then you would not be able to have language set independently of the country unless the language settings were per page.

If anything is able to be made clearer in the settings to achieve the above, then great.
tom

Developer

tom

25 Aug 2010
Posts: 379

I'm not looking at changing the current functionality, which is as described above, just removing duplication and reducing potential confusion.

At the moment however the language table still has fields for root and home which I don't believe are used any more, so I'd like to delete them. The language table itself will remain, but just to handle html language settings for pages.

There will still be residual confusion in that the lang_country setting is actually not necessarily to do with either - it's just a way of defining sub-sites within a site - and that by default it gets populated with a list of languages.

It may be preferable if instead it just got setup with one field, maybe called 'global' or something with the default language set to en, root 0, homepage 1.

Then if you want to set up a multi-section site, you add extra fields to it, defining the root/home for each as you do so, and adjusting the 'global' setting as necessary.

The (html)language field should, absolutely, still be available to be set from within edit page.

The lang_country field could I think be hidden though (or even disposed with altogether) - if a page is under a lang_country root in the page tree , it should be considered as belonging to that lang_country. And it should be easy enough to discover as both $roots and $selectedpages are I think globally available.

I don't think that would alter how it works at all and would remove the (currently very large) potential for editors to create pages that don't work properly just because they forgot to assign the lang_country field to a page (but put it in the correct lang_country section).

yes?
searchmaster

25 Aug 2010
Posts: 19

Yes, the language/country should be prepopulated with several common countries like au, uk, ca to use as examples rather than the current languages which is a double up.

If a new root is created how is it created - chicken/egg situation if the lang_country field is hidden and yet needs to be set. Yes, I understand about the inheritance for inner pages. So fine to have it hidden for inner pages. So then if a parent page is set, it gets hidden, but if the parent page is not set, then its available to be changed?

Seems like all your logic is sound! Sweet.
tom

Developer

tom

25 Aug 2010
Posts: 379

the root is just a page like any other, and what country/lang/whatever it belongs to could/should be set in the lang_country table, rather than in the page table - that's why i wonder whether the field in page is actually required at all. I need to check that more throughly though.

I'd rather populate the table with something generic than specific - languages or countries - and with as little as possible.

It seems like most of the multi-sites you're setting up use countries, all the gH ones are sectioned by language, others may have other uses for it altogether (region, brand) - so I'd rather not presume that at setup. It's confusing with two sets of languages, but I think it would be equally confusing to have one language set and one for countries for people setting up sites sectioned by language who then need to know that countries doesn't necessarily mean countries.

It does seem like that kind of confusion is what led to the lang_country table coming into existence in the first place - the functionality was already there in the language system to change the table entries from languages into countries (and have it work as it does now) but perhaps wasn't obvious because it was called 'language' and pre-populated with languages.

I'd like to avoid that happening again.. :)
searchmaster

25 Aug 2010
Posts: 19

Sounds all reasonable.
searchmaster

25 Aug 2010
Posts: 19

what would be a generic name: subsite? - that's effectively what it is?
tom

Developer

tom

25 Aug 2010
Posts: 379

something like that - for the table display name - and something like Global for the default single entry in the table for new installs (might as well stay as en for the short code)
searchmaster

25 Aug 2010
Posts: 19

:)
tom

Developer

tom

25 Aug 2010
Posts: 379

stage one complete. Basically just a cleanup.

Will get to the pg_language issue eventually, but probably best to leave that until a reasonable chunk of plugins have been checked through for consistent use of the getMultiLanguageString function (which is itself something of a misnomer) rather than trying to do their own thing. A lot easier to update things at one place in the core than try and 'fix' every plugin after the fact.
Back to Forum Index : Back to Plugin Announcements Page << [1] [2]  RSS
You must be logged in to post a reply



You need to Register or Log In before posting on these forums.