Panels Import

fix mistake

@patrickd

but why not using features for this? Is there a real advantage?

Yes, definitely! Features really great module, but it makes all in one. Sometimes it is difficult to maintain.

Example: If you have 10 panels then all this panels will export to one file. It means what:

• If you want to remove one, then you will need to look for it in this file.
• It will be very complicated to tracking changes via version control system.

it's not a good practice to let other people change anything in your modules directory, as this makes it really hard to update because you can't just replace it with the updated version. rather use an external directory for this.

It's really good idea! I can use sites/all/import folder! I will do it, thank you ;)

Also I'll try to sort my project page and code style ASAP.

Thank you!

• Files for import is moved to sites/all/imports
• Project page is looks better :)

There are a lot of hard coded stuff - if you for instance works work installation profiles you are left outside.

You can just add it to dependencies[].
Also, I'll add multisite support #1588900: Multisite support

How does this work together with Features module?

This module can works separately, however we use it together.
For example: if the some module depends on the panel - we use Features. All uncertain panels use panels_import.

When you add content in pages/mini panels panels import does not check for dependencies, things are just broken if the dependent module is not active/missing.

It makes sense. I'll do it soon #1658822: Notification about dependent modules

When you move or delete the page (.inc) that the import is done from, is disappears from the database.

If panel is Overridden then after delete .inc file - panel is still in the database.

If you already have a panel with same name, it is overwritten by the imported panel, and it is marked as overridden, and when you revert it is the panel that is in the file that you have left.

This is expected behavior. Features module operates in a similar way.

And how does this differ form how Features handles panels? On your project page you write "But it makes all panels in one file and sometimes it's very difficult to maintain." But that is not correct. And the maintain issues should be the same when you do it look you do with your module.

Most important thing that you can put all your panels to one folder, and maintain them there.
It's very useful if you have a lot of panels without modules.
If you have panels owned by module - in this case it is better to use features.

No permission settings, if the module is activated, all panels and pages are imported (adding security tag for this, is not complete sure if that is accurate).

I don't see any reasons for security check, because this is expected behavior.

If you add a view pane to add that to a panel, and export that panel - you do not get the view with it, so it is not going to show on the panel.

It makes sense. I'll do it soon #1658862: Notification about dependent Views

Thank you :)

I'm so sorry if I offended you, I really did not want to do it :)
I think I understand what you mean about profiles. Now you can use 'sites/all' folder only. I'll fix it #1659072: Profiles support

Sorry again:)

add git links