I just noticed while adding a blog post to silverstripe.com that somewhere in the past few months we broke the insert-flash object; you can choose a folder but no objects appear to insert into your HTML Editor. Elijah's having a look at this ...
We've moved the forum!
Please use forum.silverstripe.org for any new questions
(announcement).
The forum archive will stick around, but will be read only.
You can also use our Slack channel
or StackOverflow to ask for help.
Check out our community overview for more options to contribute.
- Previous 10 entries
- 1
- Page 22(current)
- 3
- 4
- 5
- Next 10 entries
> somewhere in the past few months we broke the insert-flash
> object; you can choose a folder but no objects appear to insert into
> your HTML Editor. Elijah's having a look at this ...
Here is a patch that fixes the Insert Flash button: BUGFIX-Make-Insert-Flash-work-cms-sapphire-gsoc-r38163.patch
I've tested, and this patch applies cleanly to silverstripe-v2.0.2-rc2.
I'll commit this to the gsoc branch.
Hope this helps,
Elijah Lofgren
> ChangeLog since 2.0.2-rc1:
> db/build authorisation fixed for dev sites
I installed SilverStripe 2.0.2-rc2 on new.elijahlofgren.com which runs Apache 1.3.37 (Unix) MySQL 5.0.27-standard PHP 5.2.3
It installed fine, but I was unable to run /db/build until I temporarily commented out this line in sapphire/core/model/DatabaseAdmin.php:
BasicAuth::requireLogin("SilverStripe developer access. Use your CMS login", "ADMIN");
I tried setting this in mysite/_config.php, but it did not work:
Security::setDefaultAdmin('<admin login>','<admin password>');
Anyone else had problems with running /db/build on 2.0.2-rc2?
Note, I had the same problem with 2.0.2-rc1.
Thanks,
Elijah
This was an area that Andrew worked with on the last release so is probably why you're finding this ... basically you DO want protection from running db-build, but it seems it now may be too hard to run it :P
I think a rule, say in _config.php along the lines of
if (http_host=='localhost' or http_host begins with 'dev.') then devmode=true
(Sam and I had discussed an interface in the installer to do this, however I'd suggest the above instead, for the sake of speed and not introducing issues; I'd really like us to release 202 ASAP as I want to mention it in a newsletter in a few days)
Additionally, though, wasn't Elijah's problem the fact that while /db/build did ask for a password, it didn't let him type in any password to actually let him proceed ...
> Additionally, though, wasn't Elijah's problem the fact that while /db/build did ask for a password, it didn't let him type in any password to actually let him proceed ...
Yeah, it basically wasn't accepting any password. However, it works on Apache/2.2.3 (Ubuntu) PHP/5.2.1 so I should do some debugging to see what the problem is.
Off to eat supper,
Elijah
Sam, what about the trigger that enacts http_basic_auth on "test" sites? Is that another thing to put in _config along the lines of
if (http_host begins with "test.") enforce-basic-auth-for-viewing-site()
(like my code ? :P )
Or is this something we manually enforce and isn't hardcoded in the distrubution? (in which case we do nothing for 202)
> It shouldn't ask for authorisation if the site is in dev mode. Should I add code to the default _config.php to put the site in dev mode by default?
Thanks Andrew!
Adding this line to mysite/_config.php makes it possible to run db/build without asking for password:
Director::set_environment_type('dev');
Maybe it would make sense to add the following lines to the default _config.php file?
// Uncomment the line below to enable passwordless access to db/build
// Director::set_environment_type('dev');
Thanks,
Elijah
- Previous 10 entries
- 1
- Page 22(current)
- 3
- 4
- 5
- Next 10 entries