A note about Drupal 7.x bugs

Pardon me if you've answered this elsewhere, but why is the 7.x branch unmaintained?

And, if it's unmaintained, why does it even exist? I would rather have been told that there is no D7 version, than have just spent half an hour trying to figure out why this module didn't work.

Hmm... Ok.

May I suggest that the #D7CX pledge be removed from the description? That pledge is a large part of why I assumed that there as an active D7 branch that worked decently.

Also, mentioning, prominently, that the D7 branch currently has no maintainer would be helpful.

If there is no maintainer for it, should there be a recommended release for the D7 branch?

I understand the frustration of others on this thread, but maybe a better question is whether aidanlis would consider one or more co-maintainers for the D7 branch. If not, then perhaps it would be better if there was a fork ( ie, completely new project / module ) for the D7 branch. In which case, it may be less frustrating for the existing project if the D7 version was completed removed here.

Aidanlis, please advise.

I wonder if part of why it's not maintained is this comment by Deciphered: http://drupal.org/node/691078#comment-2574192 This module might be one of the ones held up.

this is one of the essential modules to have a clean file system and i started to use it without the knowledge of the status ...
i'm not a developer, but i would spent some money ...
and maybe think again about a co-maintainer - maybe somebody discovers his/her special love for this module :)
or a company want's to increase their prestige in the drupal world ...

I think the problem is that no one is volunteering to be co-maintainer. The description does say that they are looking for one, or more.

If I had the skills and time I'd at least look into it, but I don't. :(

I don't know if this is the right place for this question.I want to have the functionality of this module for my drupal but it seems the project is unmaintaind for drupal 7.I want to rename my images to current timestamp during the upload process.Is there another way to do this?

here is a chipin field: http://drupal.org/node/691078

http://www.chipin.com/

maybe some one of the maintainers could put it in ...

thanks

I will not be allowing Chipin to cover development of FileField Paths, I am strongly opposed to any developer taking money before the work is done. I'm not opposed to taking money because you like my work and you're just showing your appreciation, nor am I opposed to doing paid work on contrib modules, but never will I take money with the promise of doing the work upon receiving the money!

As aidanlis stated, I don't currently have time for FileField Paths, that does not mean I have abandoned it. There are two co-maintainers looking after patches, admittedly neither of them would consider themselves an expert on the module, but it's better than nothing.

My time is very limited at the moment, but I can tell you that FileField Paths is the next of my contrib modules that will receive major attention, so instead of complaining, I would suggest someone compiling a nice list of bugs and feature requests so that when I do get back to FileField Paths I can get it knocked out as quick as possible.

On a side note, I will state that FileField Paths for Drupal 7 can never really have a stable release until the epic Field Tokens issue (http://drupal.org/node/691078) is resolved, this is the reason that development ceased in the first place, and the issue is a major hindrance to many Contrib modules.

Cheers,
Deciphered.

Deciphered,
I saw that token issue, it is indeed a monster. We appreciate all the work you've done with this module, it's only because it's so great that everyone is so eager. :P

subscribe

I totally agree with #7 - this is one of the essential module to have a clean file system. I hope that the D7 version will be maintained and there will be new releases.

subscribe, I hope somebody fix all those issues cause using ff path is a nightmare atm :) . Is there any other module with sort files, with help of tokens (node related), in drupal ?

sub

Subs!

It seems that http://drupal.org/node/691078 is fixed.

Subscribe. Can't use this module with token with errors.

i am currently xdebugging the module for some hours to understand the concept and fix some bugs in the 7.x
i will post if i made some progress.

e-anima,

I appreciate it, I did re-look at getting FFP7.x-2.x going, but I still haven't had the time, biggest reason being the old 'scratch your own itch' policy with Drupal, I haven't had a huge call for FFP myself for a while, and had itchier itches to scratch...

I would be happy to discuss anything via email if you (or anyone else) is actually serious about completing this port with an actual understanding of the module and what it does, so if that is you, send me an email via my D.o. contact form.

Cheers,
Deciphered.

aidanlis. maybe. but at the moment i am trying to understanding the concept so that i have a solid base for working on that. if i have the main logic i can optimize and stuff.

I am using a sligthly modified 7.x-1.x version of this module for a long time. I'm attaching it for your pleasure :-)

@omercioglu. you mean with your patches posted in the issue queue applied?

@Deciphered, if you could answer one conceptual question shortly it would help me (if possible). Why are there so many custom hooks implemented (and all dynamically too as seen in hook_invoke, what basically goes through a lot of modules)? Basically file.inc and image.inc are 99% same source, only some small checks differ.

Not wanting to complain, but just wanted to add my voice in saying that this is a fantastic module (I do believe it is critical for file-heavy sites), and I am among those eagerly awaiting a D7 version.

I don't think I have the background necessary to do very much on the development side (though I will take a look), but I will certainly follow along with the latest 7.x dev releases and point things out where I can.

The best thing that anyone could possibly do to speed up a decent port to D7 would be to start working through the issue queues and identify all valid issues and link to them in a meta issue so that when I start working on the new port I have easier access to the valid issues.

Additionally, identifying any duplicates and marking as such would also be a huge help.

Cheers,
Deciphered.

I'm using a mangled version of 7.x-1.x-dev (2010-Nov-25). I'm using it for over 9 months now. I've made a diff between my version and the latest 1.x-dev, and i can see that most of the keypoints have changed substantially. Sorry that i can't help more than this right now. I have to use this module as is since it works for me as i expect. Perhaps i can try a debug session and see how exactly it works and do a complete (basic/simple) rewrite.

omercioglu that is exactly what i try to do

So will somebody fix this module so users could use it without problems ?

I guess we don't have other choice but to use it, cause there is no alternative. Some of its options are great and it should be build in core (after fixing them to work properly).

i have restructured the module and fixed osme bugs. BUT i completely killed all "update/batch update" features. in my opinion this should be in a spearate module file and on a settings page, not inside the field settings.

and i removed some other things. i am not sure if deciphered as maintainer agrees to all of that.

@aidanlis,

Unfortunately this goes against everything I believe in, I don't take donations for development of a module, nor bounties, any form of money prior to development is completely against my beliefs.

I do however have the capacity to work on modules on behalf of a client, which is a completely different matter.

I do understand the need for this development, given the high usage, and it will get done as soon as I have time, but my personal life does not always allow for as much development time as I'd like.

@aidanlis: There is absolutely nothing to stop capable developers from checking projects out from git, working on the issue queues, creating patches to fix issues, or even maintaining a forked sandbox if there are a lot of fixes necessary for the code to work. All of these things do not require the project maintainer at all. Anyone developers who are sitting around hoping obviously don't know how to contribute to this community.

honorable approach Deciphered. But only possible if you can do this as you said "If a customer pays for the development".

@others And as i said i am currently working on that module. I only needed to restructure it a bit and removed the auto update feature. All said above.

As far as i can see there are a lot of custom hooks that would allow other modules to access the features of filefield_paths too. APi like stuff, but documented nowhere, so i bet no other modules, except deciphered own modules use that.

So i think i will release it when i am finished. Maybe with a new name/project "filed_paths", beccause it will be very different in code from this one.

@Deciphered "any form of money prior to development is completely against my beliefs" I understand that and respect your beliefs, you are honest man I won't convince you to change your mind.

However you should direct ppl in some way. I think that most user just want to use this module with it's great functionality without any errors...

they want to simply put "news/[current-date:custom:Y-m]/[node:nid]" Image Path, insert some pictures via insert/media/basic image field module and then open them via colorbox/lightbox2 module and 'Retroactive update' rest of the images. If this will be possible than any new features can be developer later on. Basic functionality of this module is broken and that why ppl moaning here - to fix this asap.

Just write few word what do you think should be fixed in first place - like - lets fix that you don't need to set colorbox/insert patch every time you save/update node (probably cause of this (?) - When you are creating or updating a node the full values for the Node tokens may not yet be known by Drupal, so the FileField Paths module will upload your files to a temporary path based on your filepath pattern ('files/[nid]') and then once you save the node and Drupal is provided with the Node tokens values the file will be moved to the appropriate location.).

and ppl will work on this.. test it... make some patches. I think this is needed cause some of the developers don't know the plan and are afraid that their work will not be implement/they are not sure how to address issues - they simply don't want to hear "this is not the way I want it to work".

Also ppl want to make sure that when they install this module it will be upgraded (maintained) and there won't be a situation - "sorry, we are not going to develop it further and now you need to fix all of it on your own".

I do not have programing skill so I can only show some bugs with a short description how to reproduce it (and some times it's not even related with FileField source module) so I may misunderstood the situation but I think it will help others to see what we are fighting with and that the drupal guru is coming back from time to time to check if everything is going in a right direction.

well, just check out what deciphered is doing, amount of modules he has at his profile. maybe the release of fielfield_paths shouldn´t be gree and should be dev only. the people will not think ok yes its green its rockstable.

field_file_paths? not really. field_paths match that as you alter the paths of fields, atm its only file and image but theoretically it could be anything holding a file.
sandbox :) im not finished with my git setup and my code is not finished neither.

@aidanlis,

Given that you have co-maintainership of this module, you should be the last person complaining that there is nothing being done, because you have 100% ability to make sure things get done.

Why recommend another split (which you've previously threatened) when you have the ability to take that code and use it to benefit this module?

As for saying "I'll get to it when I can", maybe it does deter others from working on the project by giving them false hope, but Drupal is and always has been a scratch your own back community, I wrote the module because I needed the module, since then I did my best to maintain the module, but continuously maintaining a module that works perfectly for my personal needs is a lot of work that I haven't got time for and prevents me from tackling other development. If I had co-maintainers that could help keep the module on track, or even just the issue queue on track we might not be in this situation.

But as I stated, I know this module needs work, and I'm now committing myself to do that work, so how about we stop bickering about this and those who really want this stable within the next few weeks, instead of wasting your money on donations that I don't condone, or bickering, help me get this done be sorting out the valid and invalid issues, the duplicates, the important features request, etc.

Meta issue is setup at: #1326134: Meta issue for Drupal 7 port

No I'm not reading, I'm skimming because I've got little enough time to do anything let alone read through every comment, so if I've misinterpreted you I apologies.

Development of FieldField Paths for Drupal 7 has resumed.

Great !

Ok, at the risk of getting totally flamed, is there a possibility of a release soon? I saw the post about token-7.x-1.0-beta4 using the new basic token structure and I wondered if that is enough to fix this module?

@e-anima Were you able to make progress on your version? I know you said it wasn't finished, but as Webchick says "fail early, fail often". If it fixes several issues, post that puppy up so others can help.

Being able to use this module is becoming more important to us all the time, however it won't matter if the underlying token issue isn't fixed. So not trying to complain, just asking (gently) for a status.

Hi crimsondryad,

The primary hold up is that at last check there are too many un-reproducible issues, I'm not going to release a stable release with major known issues, but I can't fix them if people just respond with 'this is an issue for me to' but don't give me any viable information so as to reproduce the issue.

Secondarily I have way too many time constraints at the moment, this weekend is Drupal Downunder which a lot of my personal time has gone towards preparation of a presentation, and other time has gone towards other modules that also require my time.

And of course family life has to fit in there somewhere.

I will turn back to FileField Paths as soon as I can, but unfortunately the timing is just off, especially when only these last few days I've had multiple requests for additional work on multiple of my projects.

I wish I could promise more, but that ends up with disappointment. The only guarantees I can make on my modules is for clients or sponsors, which is not in any way saying that it is a requirement for someone to pay for a Drupal 7 release of FileField Paths, because that is the exact opposite of my core beliefs. But if someone required the work be done I am always available on a professional bases.

Cheers,
Deciphered.

I'm not asking for a stable release. If there are some things that are fixed though, another beta wouldn't be bad so we can get partway there.

I understand totally about being slammed. I may be able to get someone on my team to gander at this.

Re-closing this issue as it was closed and and didn't need to be re-opened.