After a great discussion with Kreynen today, we've worked out a plan for some major changes to the module structure, to upgrade to the new Isotope library, and to ensure this module will work for a more diverse body of use-cases.

Feel free to have conceptual input here, and let us know if you are interested in testing.

The following features have been suggested:

  • An interface for creating reusable configurations (entities) with settings for different layout options, etc.
  • The ability to choose an existing configuration from the view settings
  • The ability to differentiate "instances" to allow more that one isotope gallery on a page (filters can link to an instance)
  • Use new Isotope library and remove reliance on jquery_update

The suggested module structure is

  • views_isotope_core: Core library inclusion, config UI, etc.
  • views_isotope: views plugins allowing choice of config
  • views_isotope_ui: Adds fields to configuration UI allowing the user to easily override CSS column widths, etc. (This is an optional helper module - editing your theme's CSS is of course better)

In order to progress with this, we have created 7.x-2.0-alpha1, and we will begin making radical adjustments to 7.x-2.x-dev.

To reference earlier discussion, see:
https://www.drupal.org/node/2224023
https://www.drupal.org/node/2315983

Comments

serg2’s picture

serg2 commented

It is great to see some work being done on this. I have been using https://www.drupal.org/project/masonry in the past but would like to transition over to using Isotope & https://www.drupal.org/project/views_isotope. This way I can use the masonry layout to replace my old work and use the isotope/ packery layouts where appropriate.

My development skills are low but I am happy to test alphas/betas/devs etc .

Chris Gillis’s picture

Chris Gillis commented

Great to have you on board Lostandfound! I'll be doing most of the dev work on this. It will be fantastic to have someone testing the process of shifting from masonry to isotope/masonry. I'm hoping we can make that process as smooth as possible. :)

Chris Gillis’s picture

Chris Gillis commented

As per #2047707: Apply different view styles to filter block. we can look into the option of allowing a filter block to use a different view style. A filter block should really be able to use a view style provided by a different module, and still be able to act as a filter. We could consider a filter "field" instead of a view style...

deajan’s picture

deajan commented

Hello,

Glad to see that the module developpment is continued.
I've read you released 7.x-2.0-alpha1 as a "point of no return" release.
As i made some changes to the 7.x-2.x-dev module, is there any good reason like a huge bugfix for me to update and port my changes to the alpha version ?

Regards,
Ozy.

kreynen’s picture

kreynen commented

The alpha version was just the version numbered release of the last dev snapshot. If you diff the alpha from your copy it is unlikely you'll see any differences beyond your changes and the version info packaging adds to the .info.

That said, it would be helpful if you opened a new issue and included a patch of the changes so we can take your usecase into account in the updates. Ideally you'll be able to run future releases of the 2.x branch and get the look/behavior you want without needing to modify the module.

deajan’s picture

deajan commented

Thank you for your fast answer.
I actually did post my use case some while ago here https://www.drupal.org/node/2294137 but i must admit it's more a dirty hack than a nice patch i did.

Results can be seen here: http://www.vacances-groupes.com/montagne
I use the images fetched from taxonomy image fields as isotope filters with taxonomy terms attached to them for the filters to work.

Also, following this guide about triggering isotope layout after all images have been loaded made my day:
http://isotope.metafizzy.co/appendix.html#imagesloaded

Regards,
Ozy.

Chris Gillis’s picture

Chris Gillis commented

@deajan
I had noticed your feature request for the ability to use images as filters, and I'm hoping that we can achieve this in the next release. This is actually tied directly to #2047707: Apply different view styles to filter block.

deajan’s picture

deajan commented

@kreynen @Chris Gillis
Well i wish you good luck with the work. Thanks :)

flatfeat’s picture

flatfeat commented

Thank you, really looking forward to seeing continued development on this module.

gausarts’s picture

gausarts commented

Feel free to have conceptual input here...

I hope this is not too late to share my thoughts. Forgive me if it is.

IMHO, having views_isotope_core as the main module within the views_isotope package/project namespace is a bit confusing, at least for me.

Currently it is still at DEV which is not committed to the next alpha yet, so I think you have freedom to change/re-structure it where appropriate.

Since it is views-centric, I would think the following worth considering:

  1. The main module is better back to the views_isotope like the 2.x alpha and 1.x. It will contain the CTools configuration database. views_isotope_core can be dropped after moving its contents into the views_isotope which is now almost empty. This also means not too much different from 1.x to 2.x.
  2. views_isotope_ui is more suitable to contain the CTools export UI admin which can be uninstalled like any UI without affecting the main module functionality.

I am willing to help moving the 2.x branch forward if possible, but currently stuck with the architecture.
If the maintainers could shed more light on whether it is the final architecture, or still open to re-structuring, that will be very helpful.

Thanks for considering it.

gausarts’s picture

gausarts commented

I just noticed there was intention to integrate with isotope.module mentioned here:

The next release of the module will add a dependency for http://drupal.org/project/isotope to address this

I think it is a great idea, hopefully still open for discussion, although it seems never made it so far.
But I think it is better late than very late ;)

This may be a simple solution to the problematic views_isotope_core namespace.

With such idea in mind, I am now imagining like this:

  1. isotope.module, is the main core module containing the library, CTools plugin definition and its database as already started by views_isotope_core. A few adjustments may apply. And of course, we need to talk to the isotope maintainers, too. But that can be done later when we have a solid formula here.
  2. isotope_ui, the backend export UI.
  3. isotope_views, or views_isotope, is the actual implementor to integrate with Views. This stands as it is now, a contrib.
  4. isotope_context, is to keep historical integration with context, if any interest in it, but now a contrib like views_isotope.

It is just my 2 cents, of course.

IMHO, this is fairly solid, and also common to 3rd-party integration modules: Masonry, FlexSlider, Slick, etc. which have similar architectures.

I would be happy to talk to the isotope.module maintainers later after hearing from you here if such integration is worthwhile.

I realized most maintainers are busy, so again I am willing to help move this forward.

I am also happy to just continue what was done if that is more reasonable. Yet your idea to integrate with isotope.module seems more solid.

What do you think?

Chris Gillis’s picture

Chris Gillis commented

Hi Gausarts,

Thanks so much for your input. Part of the problem with this is that there are multiple modules existing for something that is really very simple. I personally think it makes no sense for there to be multiple isotope modules... Using isotope without any module is easy enough, just adding some JS. Having a module is handy for people who can't or don't want to do that, but having multiple isotope modules is just silly. This module started specifically being for views, but with the latest version I have removed that dependency, with the goal being that eventually this will be the only isotope module necessary. At that point we can begin discussions about taking the "isotope" namespace, and dropping the "views_" prefix.

You'll notice in the latest dev that you can use isotope for simply theming a list... no views required. Views integration is then a bonus. I still have work to do on this, which I would very much appreciate your help with... extending to use infinite scroll for instance.

This module is now the only module to use the latest version of isotope and to allow it to be fully and extensibly configurable. In that sense it does what isotope.module does and more. I understand that the "views_" prefix is misleading, but I'm not willing to split into multiple projects. Fewer dependencies are better.

Also, I'm sorry that I haven't had a lot of time to put into it lately... I'm aware I need to get it finished and stable before I start on a D8 version (which I'm hoping to do soonish).

Chris

gausarts’s picture

gausarts commented

Thanks for your thorough reply.

It is normal to have hiatus. Most maintainers are busy AFAIK.

Yes, agreed some can simply do it without any module. But you never know how many of those who still need one. It is 14K+ now and more tomorrow.
IMHO when it is named a module, it is okay and worth modularity for easy maintenance, not necessarily silly ;)

The latest DEV is already modular, which is already great.

I like your idea about the views_isotope_ui which will surely make it lighter at front end as people should be able to uninstall it and reducing free some memory without affecting the functionality. It is common to solid modules to have separate UIs.

And to extend what you have outlined above, perhaps the CTools export UI and backend stuffs should go into views_isotope_ui as well. Thus need moving the only function hook_ctools_plugin_directory() of views_isotope_core and its plugins directory into views_isotope_ui.

It is still DEV and not committed to the next alpha yet, so it'd better to shape it so long as you provide docs/comments to solve possible issues so that adopters are informed earlier.

Little swears are normal, we all should learn how to deal with moving modules one way or another anyway ;)
It is part of the learning process.

Perhaps this info can go to the homepage later on with the above move:
When updating to 7.x-2.0-alpha2 above, clearing cache and class registry is required and can be done using Admin menu. Only if still trouble use registry_rebuild module to clear the registry for good.

I am still wondering though whether the views_isotope_core as the main module within the views_isotope namespace is worth keeping?

What do you think?

I am happy to hear whichever the best direction will be. That will be okay.
Looking forward to the best in the direction.

Chris Gillis’s picture

Chris Gillis commented

Hi Gausarts,

If I could list my ideal module structure it would look like this:

Package: 'isotope'
'isotope_core': Enabling this will allow you to theme lists using '#theme' => 'isotope_grid'.
'isotope_views': Relies on isotope_core and views. Enable this to get views integration.
'isotope_ui': Relies on isotope_core. Enable this to do css changes in an easy interface.
'isotope_example': A simple example module with working isotope implementation for people to copy.

There are two reasons stopping me from using that ideal naming structure. 1) "isotope" namespace is taken by an old v1 module. Our package (for now) must keep the "views_" prefix, which I admit is confusing, because not all of our modules in the package will be releated to views. 2) People who already have a module called"views_isotope.module" on their site might run into problems if that doesn't exist anymore...

Anyway... I'm hoping to get all the functionality sorted first, and then look at shifting this to a better namespace... until then I'd ask you to bear with me with the bad naming.

gausarts’s picture

gausarts commented

Hi Chris,

Thanks for detailed info. Truly appreciated.

But I am sorry I think I failed to make myself clear :/

Just to be clear I didn't question about "views_" prefixes.
We are on the same page on this part ;)

The problem is I made some distraction to my own essential question, about which I am truly sorry.

Please allow me to step back to my original comment since it is not answered yet:
The project namespace is "views_isotope", but the main module is "views_isotope_core".
This is non-standard which I said "confusing" in plain English.
Why not move "views_isotope_core" contents back into "views_isotope" since it is almost an empty module anyway?
This way "views_isotope" is back as the main module reserving the project namespace which is crucial.

My expectation was actually justified by D8 Beta development cycles.
They are okay to revert the revert even at Beta stage, so why not this module which is just DEV?

Please forgive my bold question, I asked because I was worried it is leading to some complication due to non-standard namespace.

This may start making sense when you start porting the DEV module into D8.

I am showing you some love about it. I would appreciate if you could kindly clarify this before further steps.

Thanks.

Chris Gillis’s picture

Chris Gillis commented

Hi gausarts,

I have performed some refactoring and code cleanup in the latest commit, and taken your suggestion for module renaming. My next task will be extending the example module to include, not only an example of a themed list, but also an example of a view. I think an example module is going to be the best way of documenting the new functionality.

Regards,
Chris

gausarts’s picture

gausarts commented

You are awesome. Thanks for taking this into consideration. Truly appreciated.
Yes, example (with some real-world views) would be great to reduce basic questions about the module functionality ;)

It will be great also to provide info about how to clear cache and registry as mentioned #13 later although no obligation for a DEV-BETA since most DEV-BETA users are assumed to know the risk and familiar with such Drupal routines ;)

I have no more internal conflict about todo or not todo. Now should be just

obedobedoooo...

Thanks a lot!

Chris Gillis’s picture

Chris Gillis commented
Status: Active » Fixed

I've released 7.x-2.0-beta1 so I'm marking this ticket as fixed. Here are a couple of final notes:

- I am interested in hearing the experiences of people upgrading from 1.x. I expect that to involve some reconfiguration of views, but if there is anything more serious then please open a ticket. If there is something that just needs clarification, feel free to add some upgrade notes to this page: https://www.drupal.org/node/2586201. @gausarts A registry rebuild should not be necessary. A full cache clear should be sufficient. Please open a ticket if that is not the case.

- The current module relies on people doing their own css. I have not included a default css, but I have included an example css that people can copy from. I am happy to take suggestions about the best way to simplify this process, or patches to implement a simple ui module for people to write css into a window or something... anyone who's interested feel free to raise a feature-request ticket.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.