Will Munny

+Clients
  • Content count

    1404
  • Joined

  • Last visited


6 Followers



About Will Munny

  • Rank
    Needs Serious Help

Will Munny's Activity

  1. Will Munny added a post in a topic: Possibilities for 'First Click Free' paywall   

    Exactly the answer I was hoping for, thanks.
    Yes, I take it you read the Google guidelines on the concept i.e. search engines must have untrestricted crawl access. In order to continue benefiting from search engine traffic, real human users must have the first one (or more) page views without the need to log in... thereafter, they must register.

    Sounds goood. I'll mull it over some more and then come back to pick your brains on the technical aspect. Many thanks.
  2. Will Munny added a post in a topic: Possibilities for 'First Click Free' paywall   

    I'm posting this in the pre sales forum, even though I'm a long time IPB customer, as I may be tempted into relinquishing my perpetual license depending on what information is yielded from this topic...

    I'm so sick of content scrapers and theives, I'm considering putting my entire site behind a free paywall i.e. a paywall but only registration is required for viewing. In order to continue benefiting from considerable search engine traffic, I wish to implement the 'First Click Free' concept. Currently, all of my static content is on a basic CMS I developed myself and there is no integration with that and my forum. However, I may be interested to purchase IP Content if it will simplify some kind of First Click Free system.

    So, is there any such system already in place with this software (I've not followed IPB development for a couple of years as I've been so busy) and if not, is it a simple hack to get it to work on my LAMP stack?
  3. Will Munny added a post in a topic: Full SSL support   

    Yes yes, a 301 redirect, like I said.

    There are all kinds of reasons not to use HTTPS for guests/bots... it's a resource overhead, it's slower, it presents some additional SEO risks (e.g. a broken certificate could scare off the bots/search engines)... I only want to do HTTPS for logged in members, or I don't want to do it.

    The reason I need this is many of my members (me included when I'm at home) live in a country where government agencies monitor private connections, and saying the wrong thing in the shoutbox, for example, or in a PM, could land us in very hot water indeed. Further, in my home country, it is the websmaster that is prosecuted for illegal comments made by posters, even private comments... I'd like all of that encrypted as an additional layer of protection.
  4. Will Munny added a post in a topic: Full SSL support   

    Yes, and not setting up that 301 properly is an SEO disaster.
    I'd prefer to see the https option for members only though... so, a good feature request, since many seem to need it.
  5. Will Munny added a post in a topic: Full SSL support   



    I think you must be joking. They're as different as www and non-www.
  6. Will Munny added a post in a topic: Full SSL support   



    From an SEO perspective, it's a disaster, unless there is a way to 301 all the existing http pages to https.
  7. Will Munny added a post in a topic: Full SSL support   

    I think you're kind of missing the point. I think many admins would like to activate https for logged in members. That's what I need, and how I landed on this thread... is it possible to use http for guests, and https for members?
  8. Will Munny added a comment on a blog entry: IP.Board 3.3 Dev Update: Banning and more SEO tweaks   

    Superb. Nothing more to say.
  9. Will Munny added a comment: no template assigned   

    I'm still getting this for every PM, report notification, and anything that starts a PM... I'm on 3.2.3.
  10. Will Munny added a comment on a blog entry: IP.Board 3.3 Dev Update: SEO Improvements   

    Superb. True, hi-grade SEO is finally starting to gel on IPBoard.
  11. Will Munny added a comment: [indent][/indent] now broken after upgrade   

    [quote name='teraßyte' timestamp='1322477215' post='132972']
    @PatrickThat's wrong, the code should look like this:
    [/quote]
    Thanks for your clarification... but now I;'m worried that I might have wrecked something in all my posts when I rebuilt with my erroneous edit. They look OK, but can you set my mind at ease?
  12. Will Munny added a comment: [indent][/indent] now broken after upgrade   

    I guess now I've rebuilt post content, I can now remove the above edit anyway... but itd still be good to have a confirmation it was placed in the correct area of the file.
  13. Will Munny added a comment: [indent][/indent] now broken after upgrade   

    BTW this fix only works when you rebuild post content (which is fine with me, just making sure I've got this right)...

    Just to be sure I got this patch right, the area in the file now looks like this. Is it correct?...

    [CODE]
    protected function _replaceText( $txt )
    {
    $_tags = $this->_retrieveTags();
    foreach( $_tags as $_tag )
    /* Convert old indent tags over */
    if ( stristr( $txt, '[indent]' ) )
    {
    $txt = str_ireplace( '[indent]', '[indent=1]', $txt );
    }
    {
    //-----------------------------------------
    // Infinite loop catcher
    //-----------------------------------------

    $_iteration = 0;
    [/CODE]
  14. Will Munny added a comment: [indent][/indent] now broken after upgrade   

    Groovy. Thanks.
  15. Will Munny added a comment: Page numbers can have decimals   

    This is actually quite a serious dupe content issue, with regards to SEO... Even the rel='canonical' declaration won't correct this... So, if you change your number of posts per page, the old pages are still there with these decimals, and duplicated content...

    I had this problem when I change to 30 posts per page... and the only way to deal with it at this time, is with wildcards in your robots.txt, like so...

    Disallow: /*page__st__20$
    Disallow: /*page__st__40$
    Disallow: /*page__st__80$
    Disallow: /*page__st__100$
    Disallow: /*page__st__140$
    Disallow: /*page__st__160$
    Disallow: /*page__st__200$

    ... and they'll eventually get dropped from the search engines.