Use basename in file and image devel generation

I can confirm the bug with latest D8 core --dev and latest devel --dev from today with hitting submit on default setup. Additional Info: But the images are still generated.

screenshot attached.

Ok, I guess

      $source->filename = array_pop(explode("//", $path));

is the culprit... Try this instead:

      $source->filename = end($dummy = explode("//", $path));

I'm also seeing this error in 7.x-1.3.... The site is running PHP 5.4 which had caused other issues in Drupal core. Could PHP be the culprit here as well?

@Arrow: And — what does #2 do for you?

Or try

      $path_exploded = explode('//', $path);
      $source->filename = end($path_exploded);

or

      $path_exploded = explode('/', $path);
      $source->filename = end($path_exploded);

thank you salvis, it helped

Which one?

first, i'm using D7.14 and Devel 7.x-1.3 on XAMPP

I offered a number of variants above. Which is the one that worked for you?

Please paste the one...

$path_exploded = explode('//', $path);
$source->filename = end($path_exploded);

In D8 this was fixed in passing by the patch in #1549662-9: Node, taxonomy, comment, and user are all classed objects.

I've committed the version from there to D7 -dev:

      $filename = explode("//", $path);
      $source->filename = array_pop($filename);

Hey, I just ran into this issue (on latest stable - 7.x-1.3). I was looking at the solution above and wondering why we don't just use:

Seems simpler and cleaner. Same thing would apply for _file_devel_generate() (line 21, file.devel_generate.inc).

Agreed. Do you want to post a patch?

Let's reopen this as for #13 and #14

Sure thing!
Rolled for latest 7.x-1.x

Shouldn't this be applied to 8 instead?

Patch for 8.x

It just occurred to me that we should, perhaps, be using drupal_basename:
http://api.drupal.org/api/drupal/includes%21file.inc/function/drupal_bas...
http://api.drupal.org/api/drupal/includes%21file.inc/function/drupal_bas...

Good catch, yes!

Hello,

I have also this error. How to use this patch? Under which folder I will put this file or paste this?
Currently I am learning Drupal.

Please don't switch versions, devel changes go first in D8.

You can grab the patch in #19 and use the instructions for applying it, then if it works, you might want to replace the call to basename by drupal_basename and contribute the patch back

Revised patch for D8 using drupal_basename.

Looks good to me

Pushed to D8 and D7 — thanks!

#16: devel-generate-use-basename-1375802-16.patch queued for re-testing.

@SamuelSolis: Please don't do that. After a patch has been applied and pushed into the repository, trying to apply it a second time will necessarily fail. This turns it red and we have no way to turn it green again, even though it was green at the point in time where it mattered.

What exactly was your intention?

Here is a patch for 7.x-1.3 to be used with drush make as long as there is no 1.4 release.

@torotil: Please do not post patches for release versions — that just generates confusion.

This issue is just a minor code clean-up that has absolutely no effect on execution. There's no point in hacking your Devel release version. Use the -dev version instead.

(Marking this NR to turn #32 red.)

Back to fixed as per #27.

@salvis: reality is: this bug makes my unit-tests fail. I use the release version. I posted a fix for others who have this problem.

reality is: this bug makes my unit-tests fail. I use the release version. I posted a fix for others who have this problem.

How can that be? What kind of failure do you get?

Even then, people should not hack modules. 7.x-1.x-dev is perfectly fine to use.

I have a devel-build that automatically generates content on drush site-install. Drush returns a non-zero return value if there are warnings. So this makes my builds "fail". This has nothing to do with hacking this module.

"Hacking" core or a module means applying a random set of patches or self-made changes to your installation. This makes your version of Devel unique in the world — if we had a support contract, it would invalidate it.

http://drupal.org/best-practices/do-not-hack-core
http://drupal4hu.com/node/293

This applies just the same to well-maintained contribs.

What keeps you from installing the -dev version?

@salvis: I neither modified core nor any contrib modules. I just write my own modules too - and I don't want their continuous integration scripts to fail because of warnings issued by the devel module. That's why I'm going with devel-1.3 (because in need a stable build) + bug-fixes (like the patch I posted).

@torotil:

I neither modified core nor any contrib modules.

By posting a patch against 7.x-1.3 in #32 you are encouraging people to do just that: create their own branch of Devel that does not exist in the repository. Have you not applied your own patch on your server?

What keeps you from installing the -dev version?

What keeps you from installing the -dev version?

I guess it's what he's mentioning in #40, is not unusual that CI policies require some kind of tag to pull from, a beta, a stable, and not just the --dev, so it's the same code each time.
You probably can checkout --dev in a given point of time for those purposes something like:
git co '8.x-1.x@{2013-03-07 10:38:28}'
But you'll get a detached HEAD in any case.

Devel 1.3 is from June 2012, it's about time to tag a new release...
We might want to add a policy of releasing a stable each X months (for D7) as we don't have specific feature breakpoints.
I'd say once every 3 months, or given months, Jan - May - Sep would make sense.

Hi salvis:

I don't see the issue in patching a stable release of a contributed module for fixing a bug. He is not hacking core.

If the -dev version is the recommended release, why not release it as 1.4?

is not unusual that CI policies require some kind of tag to pull from, a beta, a stable, and not just the --dev, so it's the same code each time.

Yes, that's possible, but in that case, applying your own patches is even worse than using the -dev version. Update module can tell you how many commits you're away from the latest tag, and you can also identify the exact version using git's hash. git describe --tags will also give you this information, e.g. it gives me 7.x-1.3-43-g0a498a4 in my repo right now, meaning I'm 43 commits past 7.x-1.3, and git checkout 0a498a4 will give me that version at any time.

(You always end up in detached HEAD mode, when you're not at the head of a branch, whether you go there by hash, by date, or by tag.)

He is not hacking core.

No, he's hacking contrib. The same principles apply for the same reasons.

If the -dev version is the recommended release, why not release it as 1.4?

This is the Devel module. It's continually under development. If we did what you suggest, we'd be at 1.46 or so by now, and people would complain because we'd keep triggering their update notifications for no good reason. I like to think that people who use the Devel module are close enough to development to understand how this works.

No, I've suggested it once, no 43 times :P
But yes you are right, using dev makes sense

This is the Devel module. It's continually under development. If we did what you suggest, we'd be at 1.46 or so by now, and people would complain because we'd keep triggering their update notifications for no good reason. I like to think that people who use the Devel module are close enough to development to understand how this works.

Then why not drop the 1.3 release and make exactly this statement in the module description?

(You always end up in detached HEAD mode, when you're not at the head of a branch, whether you go there by hash, by date, or by tag.)

Essentially I create my own 7.x-1.3stable branch with a few bug-fixes (in this case one trivial one) cherry-picked from 7.x-1.x.

The way I am doing this is by putting devel-7.x-1.3 in my make-files and then adding the patch with a comment that points me to this issue and a note "remove this when switching to next version".

This is a solution that has proven to work over and over for drupal modules, whereas using dev-releases has proven to break things from time to time - which I can't afford.

… so essentially you are saying that the releases marked as recommended on the module page are in reality neither recommended nor supported.

This is not the correct venue for a discussion about who should patch what version of modules and how often maintainers should create new releases. If you have a problem with (or suggestions about) the current conventions in using, developing & patching Drupal contrib modules then please open an issue against one of the Drupal.org projects and not this issue which is about image generation in the devel module.

That is the only way your thoughts/ideas will get their due consideration from the community and in the time people are just looking at this as an unfortunate rant or noise...

Indeed, I wish I could mark the -dev version as the recommended version, but d.o just won't let me do that.

In general I agree with the 'official' preference of release versions over snapshots, but I really do believe that Devel is different in this regard.

@salvis:
Sorry,it was my mistake. I didn't try to do this, sorry.