Foren / Cotonti / Core Labs / Ideas / Feature requests for 1.x branch

ErsteVorherige12

Request big features here

lukgoh
#16 29. März 2012, 18:10

I'm not sure if it has been mentioned, but I would love the ability to look at, download and use available modules, plugins and themes from the admin section, like Wordpress.

Twiebie
#17 29. März 2012, 19:08
#33690 lukgoh:

I'm not sure if it has been mentioned, but I would love the ability to look at, download and use available modules, plugins and themes from the admin section, like Wordpress.

https://github.com/Cotonti/Cotonti/issues/760

lukgoh
#18 29. März 2012, 19:12
#33692 Twiebie:
#33690 lukgoh:

I'm not sure if it has been mentioned, but I would love the ability to look at, download and use available modules, plugins and themes from the admin section, like Wordpress.

https://github.com/Cotonti/Cotonti/issues/760

Awesome!
GHengeveld
#19 29. März 2012, 20:49

Some features mentioned in the topicstart are currently being implemented as a developer package named Factory. It includes an extended version of SimpleORM (named CotORM), as well as helpers for RESTful API design and a Model-View-Controller architecture for modules. With this package it becomes a lot easier to write modules for Cotonti, because a lot of common stuff is done automatically, in a fast and secure way. For whom it is known, it's been inspired by Ruby on Rails. The main features at a glance:

ORM
Makes storing data in the database a lot easier by automatically handling the data validation and retrieval.

REST
Helps to create clean URLs for your data resources. Mostly useful if you want to output data in XML or JSON rather than HTML.

MVC
Allows object-oriented module development. Adds structure to your module code and makes implementation of the ORM even more straightforward.

While Factory is still under development (currently as a joint effort by Trustmaster and me), we'd like to have some users to try and test it. Please let us know if you're interested in developing a module using Factory. Note that it's not meant for plugins and it requires PHP5.3 installed on the server (I can help you with that if you really need it).


Dieser Beitrag wurde von GHengeveld (am 29. März 2012, 20:58, vor 12 Jahre) bearbeitet
tensh
#20 2. April 2012, 08:16

@ Trustmaster - but my request is a bit more complex.

@ GHengeveld - of course, I'm very interested :)

GHengeveld
#21 5. April 2012, 11:59

I've extensively updated the CotORM documentation, including a lot of example code.

nicafyl
#22 31. Mai 2012, 22:01
#30957 Sergeich:

drupal

...

I just want to toss in that there are a lot of people who are "stuck" with two Drupal-related situations right now:

  • There are a lot of sites still running the now unsupported Drupal 5 and there is no direct way to get from Drupal 5 to Drupal 7.
  • Drupal 7 is a very different animal. The good news is that it is a serious cleanup of a lot of old ideas patched to come close to working better. Unfortunately for Drupal 5 and 6 users, a move to Drupal 7 is at least painful and, for many, close to impossible. So much Drupal functionality is in modules. In Drupal 7, a popular set of modules has been moved into the core but thousands of users who happened to pick what seemed like a popular module ages ago are finding out they have a huge conversion task in front of them.

That's a long way of saying that a Drupal 5 and 6 importer could get a lot of these folks moving to Cotonti.

El Gringo de Linux en Nicaragua
Trustmaster
#23 1. Juni 2012, 07:34

Will Drupal 5/6 users find sufficient modules/plugins here?

May the Source be with you!
nicafyl
#24 1. Juni 2012, 17:59
#34492 Trustmaster:

Will Drupal 5/6 users find sufficient modules/plugins here?

Some will, some won't. My (now ex-) company and I have used Drupal for lots of things for ages. I have/we have also developed web sites back when you wrote HTML by hand (I even wrote one interactive site using awk) and have friends who seem to think Drupal is the solution for everything. I just wanted to say that up front so you get an idea where I am coming from.

Historically, Drupal 4 didn't do all that much fancy stuff which really started the huge "add a module" campaign. It was not uncommon for multiple modules to be introduced, by different people, to address a need. Some modules were just written to address one user's needs. As a Drupal 7 module is generally very different from a Drupal 4.7/5/6 module, folks in that boat are going to be re-writing anyway.

Those who picked more general-purpose modules (and I fall into the category with a couple of sites) picked wrong. That is, there were multiple choices (photo galleries is one common example) and pretty much whatever you picked was wrong because there is no such animal in Drupal 7 yet and what is getting designed is not a plug-in replacement. (I can explain this case in detail if anyone cares but it is really a significant design change that does more than just break backward compatability.)

There are lots of Drupal sites I know of which consist of some static pages, forums and, maybe, multi-user blogs. And not much more. For others, add photo galleries and tags and you have everything covered. As photo galleries and blogs are the most requested features here, having them should make cotonti a possible new home for people wanting something new.

I have three "more than trivial" sites running Drupal. All need some upgrades and Drupal is probably not the right solution for at least two of them.

  • The most active is still running Drupal 5 and we have some serious issues. (It is seriously broken right now because of some hosting issues which has turned a "move when D7 does what we want" into a "gotta fix it now" issue. It is not a candidate for moving to cotonti because it has what Drupal calls books, a hierarchical set of pages which make up a lot of the site. Othen than that feature, cotonti with photo galleries and blogs would be a possible choice. (Today, ocportal feels like the best fit.)
  • Another site is little more than a personal blog with comments running on Drupal 6. It also has a (not well maintained) set of web links. While it doesn't need to be updated, it would be an easy fit into cotonti. I did it in Drupal because, at the time, I was doing everything in Drupal. From others I know, this was not an uncommon approach.
  • The third site started mostly as an experiment to test out some Drupal 7 features. It has a plan and a bit of content but, based on issues with Drupal 7, I am looking for a better platform. It is/will be a bunch of semi-static pages organized into at least what looks like a few hierarchies, forums and a glossary. Other than the glossary, which should be easy to implement, this would seem to be a good fit for cotonti.

I think what I have described is pretty typical. That is, people used Drupal to do something (which may of may not have needed some fancy stuff) and when they needed another site, they used the same tool. In general, this should have been the right approach. Unfortunately, so many D4/5/6 modules now leading to a dead end has made this an unwise decision.

Note that I a not trying to trash Drupal. Dries has done something pretty amazing and the big changes in Drupal 7 are going to be a good thing. The audience I am suggesting for conversion are those who got caught in this big change.

El Gringo de Linux en Nicaragua
Trustmaster
#25 1. Juni 2012, 19:14

Could you identify this "module trap" for D4/5/6 users more precisely: is it the old Drupal core that is no longer supported, or is it custom modules they have that are no longer maintained? Do they experience problems keeping their existing sites alive or do they have problems getting new features into them?

May the Source be with you!
nicafyl
#26 2. Juni 2012, 17:10

Two separate issues:

  • There are only two Drupal versions supported at a time. As Drupal 7 has been out for some time, Drupal 5 is no longer supported. That means no security updates and potential compatability issues. (For example, Drupal 5 will not run on PHP newer than that version 5.2.x.)
  • While there is nothing that says an old custom module cannot be maintained, they tend not to be. Lack of core fixes is part of that and another is that improvements may take advantage of core features or other modules that don't exist in an older version.

My "disaster" was that my Drupal-5 based site was running on shared hosting. One morning, at about 5AM, the hosting company decided it was using too much in the way of resources and turned it off. They didn't tell us until 2 hours later -- after I asked for help trying to figure out why it was down. (I am pretty hacked off about this as the site traffic had been pretty stable for at least the last year.)

In any case, I needed a quick fix. I had another shared hosting account. While I knew it wasn't the right long-term solution, it was the quick fix. I moved it, got DNS pointed, ... Got bit by the default PHP 5.3.x issue. Fixed that. Now, they "automatically" decide if you are using too much in the way of resources and turn off your database connection "for a while". The result is regularly broken tables. It also means attempting to move the site pretty much guarantees it goes down because of all the accesses for the dump.

Right now, all the image galleries are broken as a result of getting automatically shut down during an upgrade. Now, most of this is not a Drupal issue but it's reality. In the mean time, we had been looking at how to get to Drupal 7. Looking for over a year. Ignoring the migration issue (migration tools only handle going up one major release and we need to go two) Drupal 7 has some serious changes which make our current photo gallery approach not work. So, we remain in limbo with a limping site.

I mentioned the "too many choices" issue for modules. Here is an example. There are (at least) two different modules to add WYSIWYG editing to Drupal. One supports a specific editor, the other supports about six editors. For a site I am working on (that will probbly become a Cotonti site instead of Drupal), I picked the first one, figuring it was more likely to "work right". There are problems. So, I need to try out two modules and six editors to find something that works right. A clear issue of too much choice is not a good thing.

El Gringo de Linux en Nicaragua

ErsteVorherige12