[@hnla Participant 16 years, 3 months ago]

@xevo

Good point, although there will be tears before bedtime when people try and modify this sort of work I would have thought.

[@hnla Participant 16 years, 3 months ago]

I was wondering whether it was a theme or an app, it certainly looks like an app? could it not be so?

btw it’s a great effort, looks like a lot of work has gone into achieving that layout!

[@hnla Participant 16 years, 3 months ago]

@Duvy

Looking at your layout shows some critical issues. You describe an element twice and give it the ID #container. ID’s are unique tokens that are only allowed to be used once per page and as such are generally applied to major markup framework structures #container is one such framework element that generally would occur once along with IDs such as #wrapper. It is an error for it to be used twice and that needs to be addressed first. If that element really does need to appear as a parent of #content you could change it to a class but better is to rename it altogether (second occurrence) However neither of these elements appear to have any rules associated with them so I wonder if things are not getting slightly mixed up here?

#content has the property clear:both this will (and does) have the effect of clearing any previous floated elements or columns and is why it positions itself below what appear to be your sidebars, also it’s full width; in a basic three column layout you would need to add margins left and right equal to the sidebar widths doing both these things will pull that #content area up to the top, but the right sidebar will remain cleared below as it’s a floated element and follows after non floated content and must drop to the next available line and would require source ordering tricks to enable it to take position alongside #content.

tbh at this stage I would be suggesting that you step back and revert to the previous styles as this feels as though it’s got a little out of hand and it’s difficult to correct in it’s present state. Start afresh and work through changes carefully perhaps seeking advice as you go. One of the difficulties is that without knowing for sure what the layout is supposed to look like or looked like before and what actual changes have been effected it’s hard to offer advice.

[@hnla Participant 16 years, 3 months ago]

“Another thing I want to point in general. If a theme has .fix or .clearfix all over it. Then run the other way”

*puzzled*

Qualify that statement!

It’s somewhat misleading. In clearing floated elements it is necessary to employ a variety of techniques to accomplish this as each suites a different set of conditions met.

The .clearfix set of rulesets you refer to is a well worn and tested method , first devised by Tony Asslet over at CSSCreator, improved a tweaked by many of us over the years. It is , in certain circumstances, the best method to clearing floated containers.

What has me running a mile is seeing empty div elements with class=”clear” used to effect clearing as it’s both unnecessary and wrong to write empty elements and use them in this way, and it bores me to tears having to route through template files finding them all and deleting them with fury

[@hnla Participant 16 years, 3 months ago]

Thanks Andy I’ll have a rummage for that in a while.

Can you clarify though, why the change? as it does make preserving child theme extended from original theme files all the more awkward. I’ll be a little more indifferent to this when I get time to properly start from scratch but for the moment have to live with extending from existing markup and styles.

I would also love a little reassurance from the Dev team that creating real themes not just skins based on existing files with mix of views and controllers. I say this only as I’m a little concerned by the decision to move the default theme into the plugin buddypress folder for ease of updating as this suggests that crucial files one may have rewritten or customized might actually be updated by newer versions and these updates will have to be identified and transposed to ones custom files.

I can understand the decision to work this way keeping default theme within an upgrade structure but worry slightly that it’s not perhaps the best route for those that do intend to spend a bit more time than simply skinning; then again perhaps buddypress is best suited to simply skinning with a few adjustments made through functions.php etc which I could live with actually but only if developers stopped trying to output naughty markup such as empty div elements used to provide clearing A COMPLETELY UNNECESSARY APPROACH AND WRONG on many counts (sorry needed to get that off my chest )

[@hnla Participant 16 years, 3 months ago]

Qualify: are you referring to the title tag or heading tags?

[@hnla Participant 16 years, 3 months ago]

Hmm active 23 hours ago ???? is this that same bug that the activity stream suffered from in 1.1.* (sorry off topic!)

[@hnla Participant 16 years, 3 months ago]

I realise there is support for json in 5.2, but have added it to my version quite happily; are you in effect saying that the plugin will only work with PHP 5.2? if so that’s tough I can’t rush at upgrading PHP as I want package dependencies preserved and had issues trying to install update from a different repo. My only other server with WPMU/BP is a live production one and I am in the midst of preparing an update from 1.1.3 to 1.2.1 so can’t test tweatstream on that at present. It’s a shame as I don’t really like rolling out plugins on a live site until I have tested them localy and on live test site. Guess I’ll have to set up a new site on the production server which does run php 5..2 with yet another install to worry about

[@hnla Participant 16 years, 3 months ago]

Back to the failing authorization issue; had a trawl through the Epi*.php files and noted in one that you were using json it then occurred to me that I didn’t have json compiled in my version of PHP so set about adding ijson 1.2.1 in the hope that this was possibly the issue and also upgraded to your latest version – sadly no luck still getting the same failure.

Out of interest to what version of php are you testing, I’m running 5.1.6 largely due to the fact that RHEL CentOS 5.3 only provides up to that version in it’s package repo and it’s somewhat problematic finding a repo that has higher version and ensuring package dependencies are maintained.

[@hnla Participant 16 years, 3 months ago]

* Fixed deny access on twitter bug.

Is that anything to do with the issue Anointed and I were having with authorization or is it some other issue?

[@hnla Participant 16 years, 3 months ago]

Coming back to this and wryly noting the lack of response to the further question I posed

The issue in my case was the damned wpmu devpro supporter plugin that included amongst it’s poorly documented files one called supporter-write.php this effectively removes the ability to make a new post and/or page by removing those links in the users blog sidebar menu – disable that file and I once more had ability to create new Posts and Pages. Of course taking out a subscription automatically gives back access but nowhere does the supporter plugin explain this to the user that they can’t create posts or pages until paying a subscription and what is further damming is that this file does not actually do what it’s meant to as it appears to have overlooked the fact that you can still post by accessing the link in the admin bar dropdown! This smacks to me of very sloppy testing on the part of the supporter plugin and frankly wants to make me cry !

Sorry isos doubt this helps your predicament – unless you are using the supporter plugin? If this an issue apart I thought that Paul said this was fixed in 1.2.1

[@hnla Participant 16 years, 3 months ago]

@Michael Removing via CSS is not the same as dealing with it server side. CSS is simply a presentational language which is applied to the DOM, in order to have been able to remove via CSS requires that the elements had been outputed by the server, i.e sent to the browser; the form elements still exist. If grabbing the page using CURL or some similar means you would have that section of the form available.

Wrapping the form section in a php conditional means that as normal the file is passed to the parsing engine to process and compile into the final file to send to the browser, it sees my instruction to ignore that section so simply never includes it in final output.

I do not claim this is the best approach but it works, I do not want users to take a blog initially I would rather it a considered decision once members. Using this approach I have had no further spam blogs (other than real human twits signing up) still get user signups but at least no blogs are created.

@Andrea_r

Thanks wasn’t aware of that plugin, however do think that given the options exist exist in the backend that they could have been better thought through or even simply better worded.

[@hnla Participant 16 years, 3 months ago]

Likewise my install is a clean one. live test install WPMU 2.9.1 / BP 1.2.1 no plugins other than BP, and it’s simply running the default bundled theme. I intentionally do not customize this install.

[@hnla Participant 16 years, 3 months ago]

Have to admit I had no idea there was another registration.php page and it would have never have occurred to me to look in the bbpress folder.

This kinda worries me really why is this required and also a password reset file, it feels as though it’s a bad hangover from earlier days and ought to be removed.

Is it not time that this bbpress thing be integrated fully or at least forum capabilities simply part of BP core .

I have deleted this registration file and will be interested to see if it clears up the remaining few spam signups still being received

[@hnla Participant 16 years, 3 months ago]

@blackphantom

“keys in admin are missing”

No this is definitely not the case, I really would have spotted that

Perhaps in some way the keys are not being stored ? but would need to access the DB to check that. Any other ideas?

[@hnla Participant 16 years, 3 months ago]

@Michael

The options for account registration control are odd and do not do what they suggest (I mentioned that on another thread, but it’s a WPMU issue!)

As there were no sensible options for allowing users to signup but not take blog until a member I simply saw little choice but to remove the section of the form that dealt with the blog signup so I wrapped the fieldset in a conditional that just checked whether I had set a variable to disable or allow thus preventing that section from being returned from the server.

[@hnla Participant 16 years, 3 months ago]

@ peter-anselmo

Ah thanks for clarification I had thought is_site_admin() was a WP function, my mistake. So having a BP reliant plugin activated but not Buddypress throwing this error makes sense.

On a sidenote did I not read Andy mentioning that there is a method that is supposed to ensure BP plugins cannot error in this fashion if BP disabled? Are they not supposed to perform a check first to determine if BP is functioning.

[@hnla Participant 16 years, 3 months ago]

Definitely remove the footer link if you haven’t already.

I noticed a issue with spammers using CURL to download /registration so blocked that in .htaccess (It’s been mentioned on a thread somewhere how to)

renaming the slug ‘registration’ is supposed to help.

For me deactivating blog signup improved things significantly. Didn’t need users to be able to register for a blog at initial sign up they can take a blog once they are members.

Despite all efforts and much study and approaches instigated one after the other to gauge effectiveness before adding next one I still am not sure how a few of the automated bots get through, human signups there isn’t much you can do about them apart from delete manually.

All my efforts still result in around 10 signups daily that require dealing with manually.

[@hnla Participant 16 years, 3 months ago]

In a decent code/text editor you would see them as additional line numbers suggesting a line feed or carriage return.

After my my closing php tag I had actually induced a carriage return which is white space which qualifies as browser output.

I did actually copy your file locally and couldn’t see any obvious line feeds / white space so not convinced it’s the issue in your case.

it is definitely in your functions.php file? you haven’t been modifying a bp-custom.php file as well ?

[@hnla Participant 16 years, 3 months ago]

Well tried with a newly set up account to test this and same results.

@blackphantom

Can you shed any light on this for myself and Anointed. We seem to be the only ones to have experienced this issue so we must be doing something wrong but still can’t see quite what.

[@hnla Participant 16 years, 3 months ago]

If you’re going to fix the height of .galleryitem it might be an idea to add overflow:hidden to it’s ruleset to prevent the paragraph text overflowing that fixed height as it is in two instance or keep tight control on the slug that is generated there, limiting the number of character although anyone text resizing would still be able to overflow that content.

Nice looking page!

[@hnla Participant 16 years, 4 months ago]

div and span elements are non semantic grouping or aggregating elements, as such they are not suitable for content directly. ‘site title’ would need to be one of either heading or paragraph tag

Using a primary heading tag such as H1 for ‘site title’ a string that is the same across the site or pages is a waste of the most important document outline tag.

[@hnla Participant 16 years, 4 months ago]

I have a similar to hotdv1666 issues and have checked and double checked but can’t see where I have gone wrong.

Clean live test site 2.9.1.1/bp2.1

Twitter app set up correctly, browser type, correct callback. Keys entered in twitterstream settings.

Log in as a user and clicking on ‘Authorize with twitter’ sends me to an error page:

“

Woah there!

This page is no longer valid. It looks like someone already used the token information you provided. Please return to the site that sent you to this page and try again … it was probably an honest mistake.

“

The url to this page is devoid of possible required parameter ?

/authorize?oauth_token=

I feel as though I’m missing some crucial understanding of how this is meant to work, but can see no other parameters that I have missed or misconfigured?

[@hnla Participant 16 years, 4 months ago]

I can confirm that as just now made the same error. functions.php was already called duplicating the file in child theme simply attempts to redclare an include – there is a require_once() in the original.

[@hnla Participant 16 years, 4 months ago]

Excellent, had been wondering how to do this, many thanks.