I realise this has been covered a little over the past year or two, but I
have one specific use case I need to figure out.
Essentially, we are developing sites, but we would like to keep the code for
the site in Git (for history, and also to make deployments nice and easy).
Thing is, we would lik
> Question is, what is the best way of doing this - there seems to be
> a few
> extensions out there for copying layouts in and out of the database,
> but
> nothing that seems to make a file based layout a first class
> citizen...
We've been using the File System extension
(http://ext.radia
On Mar 19, 2010, at 1:13 PM, Josh French wrote:
>> Question is, what is the best way of doing this - there seems to be
>> a few
>> extensions out there for copying layouts in and out of the database,
>> but
>> nothing that seems to make a file based layout a first class
>> citizen...
>
> We
Jim - This is excellent, thanks for sharing! The timing of this thread
couldn't be more perfect for me.
Everyone/Josh - this fs extension pretty much does exactly what you need it
to. So far so awesome!
- J
On Fri, Mar 19, 2010 at 1:42 PM, Jim Gay wrote:
> On Mar 19, 2010, at 1:13 PM, Josh Fr
I was really hoping someone else would chime in on this...
I loaded up drag_reorder, a fork of bright4's that I did a while ago,
and sure enough get a gazillion test errors when I migrate. So, I'm
thinking, by looking at one of the errors, that it has to do with the
extension of a model's find met
On Mar 19, 2010, at 4:29 PM, banane wrote:
> I was really hoping someone else would chime in on this...
>
> I loaded up drag_reorder, a fork of bright4's that I did a while ago,
> and sure enough get a gazillion test errors when I migrate. So, I'm
> thinking, by looking at one of the errors, that
Jim, yeah that's what I responded to Arlen initially, that it looked
like his test environment hadn't been migrated with the extension in
mind.
I was on site on a project where running tests from Radiant root was
discouraged, so we ended up isolating our tests. I'm not sure what we
did to resolve
On Fri, Mar 19, 2010 at 3:38 PM, Jim Gay wrote:
> Don't try to fix it. If a core spec is defined to expect things in a
> default order but an extension changes the default, then those added specs
> will fail. The only way around this would be to undefine the original specs,
> but I'm not sure of
