You are not logged in.
Should be fixed in the development branch, thanks!
Thanks for the bug report! I've fixed this in production and it will make it into the next release.
TinyMCE and it's crazy quirks, ugh. Glad you got a workaround in place. We're hoping to expand on the file manager in BigTree 4.1 and making it easier to work with in other field types will definitely be on the upgrade list.
Nice workaround! We've never done a site that uses all the same /site/ and /cache/ resources so these are great new perspectives for us if we ever run into that in the future. When we've powered multiple sites from the same "install" it's only been a shared database with separate BigTree templates/folders. Awesome to see it doing things we never expected!
Sounds great! For a long while we didn't do any login checking on preview pages either. The main reason it's in there is to prevent search engines from indexing preview pages but you can also either use robots.txt to block /_preview/ or throw the robots noindex meta tag into your header when $bigtree["path"][0] == "_preview" and that solves that issue.
Very cool! We've been investigating things like Shibboleth for SSO but it's not something we're very experienced in yet. Good to know there's a working solution out there if someone needs it.
Thanks Michael!
If you just need to allow people to see the /_preview/ links that are being distributed manually I'd go about it this way:
Create a regular user for them (Normal level) and give them no page/module permissions.
Modify your 404 page (/templates/basic/_404.php) to see if $bigtree["path"][0] == "_preview", if it does then show the user a message saying they need to login to see the page preview (and optionally give them a link to the admin)
They'll be able to see preview pages with no permissions to anything, so essentially a Normal level user would be a Previewer anyway. You could also serve up a custom Dashboard that provides a list of pending pages with their preview links if you want to give those users something when they login.
Good catch! I completely forgot about that one.
It shouldn't be too hard to create a file browser field type. What you'll want to do is just create a hidden (or maybe a visible disabled text input) and then a link to open the file browser.
You'll want to hook the link that opens the file browser to call BigTreeFileManager.tinyMCEOpen("key_of_field","","file");
That should make it so that when the person chooses a file it will write that value back to the input field (obviously you'll want to switch key_of_field to be whatever the resource's key is).
I know the method name is kind of dumb. The regular formOpen method is setup specifically for image choosing so it's not currently as versatile. The tinyMCEOpen method is taking what TinyMCE throws at it so the parameters are a bit strange as well.
Hopefully that should be all you need, let me know how it goes!
Michael,
That sounds great, glad it's working for you! I can't think of anything you're missing off the top of my head but if you run into any problems I'd be happy to help. Thanks for sharing your solution!
If you head into the Developer tab you should be able to edit the module names, the module views, and the module forms to change the display titles of the fields.
Real localization is something we plan to implement in the future but it's a ways off right now.
You'll need to truncate the bigtree_module_view_cache table. It is a cache table for all of the module views in the admin, so if you manually add things to your view tables you need to run BigTreeAutoModule::clearCache("table_name"); afterwards in order to reset those caches.
Cool, we'll keep the discussion going internally and take your thoughts into consideration. BigTree's always evolving so nothing is set in stone (as long as it doesn't break backwards compatibility). It's entirely possible that this could end up in BigTree 4.1 (probably as an optional on/off toggle for those that don't want to have to click through alt tag prompts).
The default photo uploader doesn't store any information other than the path. If you upload things into the file browser you can set their "name" field (which is used as the caption in photo gallery fields). You could query bigtree_resources for the file name (you'll need to do a str_replace of STATIC_ROOT with {staticroot} and query for that value) and retrieve the "name" that's set for alt tags as well.
We've been discussing alt tags internally and whether we'd add support for them in the core of BigTree. Where we stand right now is that most alt tags actually impede a blind user's ability to browse a page efficiently (i.e. "Photo of girl in front of a tree" doesn't convey information that's actually useful in the context of a page, but the image itself is nice when visible).
What I've done in the past is create an override of /core/admin/modules/login/default.php to integrate LDAP. I usually add an extra column to bigtree_users that is the user's LDAP account.
I do all the LDAP connection / auth logic above the BigTree login logic in the that file (/custom/admin/modules/login/default.php). If the LDAP authentication is successful I do a look-up in the bigtree_users table for that LDAP login. If there is one, I log them in as that user. If there isn't one, I fall back to BigTree's login system (normally for developer accounts since we don't necessarily have an LDAP account with our clients).
To input the LDAP account info you'll have to add custom overrides for the add/edit page on modules as well but it shouldn't be too hard.
This is fixed in the development branch. I'm not sure if it can be dropped-in to RC2 or not, but here's the development branch's drawing code for Many to Many:
I believe this is probably a bug in the example site for RC2. In a recent release we changed tags from being enabled by default (and thus more often than not they simply confused end users since they're not often used) to having to be explicitly enabled.
If you go into the developer section and edit the blog module's form for posts you should be able to re-enable tagging there (it should be a checkbox above the field area).
I'll make sure to have this fixed in the next release — thanks for the bug report!
Just wanted to follow up that there was indeed a bug with setting S3 / Rackspace credentials in RC2. I've fixed it in the development branch but I'm going to be doing some more tweaking of the way buckets are handled over the next few days (and possibly Rackspace containers as well).
It sounds like you don't have any "actions" for your view (edit, delete, feature, etc). Did you uncheck the Edit/Delete actions when creating your view?
Thanks for catching this bug — I'll make sure it's taken care of in the next release!
I believe this is actually a bug in the RC2 release that's been fixed in the development branch. I'm going to try to get RC3 out in the next few weeks to address this.
Sorry for the delayed reply, I was out on vacation and I guess the rest of the team wanted my official response on this.
If all three "sites" are served from the same domain and you're OK with subdirectories for the "home" pages of the three sites than your assumption is by far the easiest way to make it happen. You can use the "trunk" option in Pages to specify your Main Site, Intranet, and Extranet "homepages" as the root of the site. By default, I believe, $cms->getBreadcrumb will read trunks as top level and ignore them when calling that method. If you want to get your top level navigation ID for drawing sub navigation while keeping the trunk in mind you have to call $cms->getToplevelNavigationId(true) - otherwise it will always return the Main Site / Intranet / Extranet homepage.
Using subdomains does indeed complicate things. Back in BigTree 3 I'd served multiple sites off a single BigTree install by hacking the main router to pretend that a certain Page ID was the homepage but I can't recall doing it recently. There are two things that need to be done to make that work:
A custom router (/customrouter.php) that prepends your "homepage" route to $bigtree["path"]. So if your extranet would theoretically be http://www.website.com/extranet/ you would do $bigtree["path"] = array_merge(array("extranet"),$bigtree["path"]); somewhere before the if (!$navid) { line. This also kind of breaks previewing, but if that's the route you want to go I can whip up a custom router that integrates it all.
A custom BigTreeCMS class extension that will strip out your extra path elements (extranet, main-site, intranet) from calls to getLink, getNavByParent, etc.
Support for this stuff natively will most likely be in a future BigTree release as it's pretty easy to implement but kind of hacky to do on your own right now. As for when that release will be, it could be a while as I'm buried in client work at the moment, but I'd be happy to help get your solution going if you have any questions.
It's been a while since I've checked out the Cloud Files integration so it's possible their API has changed or I've bungled something. I'm fairly sure you can't specify a container at the moment - I think BigTree creates containers based on a hash of the "directory" that the file would be uploaded to if Cloud Files wasn't activated.
Having learned recently that Amazon S3 limits your buckets to 100 I imagine this isn't the best approach and I'll be giving it a close eye in the near future. I'm caught up in other things right now (and was off on vacation, sorry for the late reply!) or I'd jump on it immediately.
We generally use Google's Custom Search (http://www.google.com/cse/) for sites we build on BigTree. BigTree has search methods for pages and modules (generally used in the admin area), but you're always going to get better search results through someone who specializes in search so we don't believe the investment is worth building a deeper search for the front-end users.
Thanks for posting this! I believe I fixed this in the RC2 release but I could be wrong (it should now automatically scroll to the top and switch to the tab with the first error). You mentioned on Twitter that you were in the "Admin demo" — do you mean the demo at http://demo.bigtreecms.org/admin/ ? If that's the case, then it's my fault for not getting the demo site updated in quite some time (it's on beta 7, we're at RC2, and I've completely spaced on getting that updated!).
If you're actually running RC2 and running into this issue please let me know and I'll look into it more. Also, your suggestion to highlight the tabs that have errors is great and I'll try to implement that in the next release.