I was wondering is there is any documentation or good resources on migrating Page models, Streamfields, and Blocks in wagtail CMS. All of this seems to not be documented much.
The official documentation has a page about StreamField, which has a section about migrations. It gives a fairly detailed description of how StreamField definitions differ from normal model fields, and the fact that migrations have been specially catered for in StreamField's design. I know that this was the biggest headache that the author faced when developing the feature.
There is also a handy guide on how to convert an existing RichTextField to a StreamField, and just yesterday, Wagtail pull request #3014 was merged, extending that documentation example.
Related
I posted a question on the Drupal forum about whether I should build my database in Drupal using content-types or the database abstraction layer and schema module: [here][1]
Any advice would be greatly appreciated.
[1]: https://drupal.stackexchange.com/questions/98020/should-i-use-content-types-or-database-abstraction-layer
I'd recommend using content types.
For a PHP coder, sometimes using the Drupal User Interface to build things feels non-intuitive, but in the long run you're going to benefit a lot from doing things "the drupal way.
Once you reverse engineer your need into a content type and all it's associated fields, install the modules that provide those field types and set things up, you'll start to see the benefits.
Validation on all the data-entry froms will already be done for you.
Multiple display modes are available for your data (email addresses can be shown with or without mailto: links, images can be shown using any of Drupal's image styles)
Integration with other Drupal modules already exists, and will be supported (almost anything built with fields is available to views)
By writing your own schema you'll need to handle all these things yourself (and more), and not just once, but you'll need to maintain all that custom code over time.
Learn to leverage the community and all the great work that's been done already, you'll save yourself time in the long run :)
What i see you are going to have shop site.
You may tray this:
https://drupal.org/project/commerce_kickstart
, i've found it usefull once. It's drupal distribution with nice themed shop rady to use straight forward.
And of course do it with content type + views + entity reference modules.
Here is a link to a comment that answers the question I asked. It backs up what arpitr outlined in their answer on the orignal post on the drupal forum, whose answer is also in agreement with jenlampton's suggestion above.
https://drupal.org/comment/7848011#comment-7848011
I will implement my system using node entities until the need arises to build a custom entity (if it ever does).
The top answer in this forum give a good way to evaluate whether to use nodes or custom build an entity:
https://drupal.stackexchange.com/questions/22586/when-is-it-appropriate-to-create-an-entity-versus-just-adding-a-new-content-type
I am building a dual language app in CakePHP 2.1.x because of the great reviews of Cake's "built-in" localization features. However, I am wrestling with getting this powerful feature to work.
I know that this topic has been tackled for previous versions of Cake (here, here, here, and here), but it hasn't been solved for Cake 2.x. I am also referencing these articles in the cookbook (yes, I've read the manual):
http://book.cakephp.org/2.0/en/core-libraries/internationalization-and-localization.html
http://book.cakephp.org/2.0/en/core-libraries/behaviors/translate.html
Couple of things -- I do not want to do separate subdomains for each language. Instead, I prefer URL based language switching with the click of a button (in this case, a flag icon). The site will be actively maintained, so the content needs to update dynamically. Asking the client to maintain two separate sites/databases is out of the question.
I have Translate behavior set up for my PostModel, but I can't tell if it's working. I also initialized I18n by running I18n in the console, have confirmed the database tables exist, have set up my .po files, and have wrapped all my content in __(). However, when I change the default language in my browser to French, the site remains in English.
I've tried the P28n Component, but I think it's outdated for Cake 2.x. I also tried URL-based language switching based on this nuts-and-bolts-of-cakephp article, but apparently it's incompatible with the new CakePHP API.
Can anyone point me in the direction of a tutorial or instructions that work with CakePHP 2.x? One not already referenced here?
Update: I found this article: http://www.localizingjapan.com/blog/2011/11/10/localizing-a-cakephp-application/comment-page-1/#comment-7467. Does anyone know where you place the code for CakeSession::write('Config.language', 'fre'); and setlocale("LC_ALL", "fr_FR.utf8");?
Simply put the code in AppController::beforeFilter() and set the values based on however you retrieve the language, from a post request or a part of the URL.
I have a web application built using CakePHP framework and now I am in the process of internationalizing it. I started with the base set-up as outlined in the below article -
http://puskin.in/blog/2010/08/cakephp-manage-multiple-language-in-application/
and also add little bit of customization based on my previous question -
CakePHP: Internationalizing Web Application
To completely internationalize my web app, I would need to translate my drop-down/look-up content as well, like - categories, favorites, countries, bucket list etc.
What is the best way to design my tables and CakePHP samples? Can someone explain with a simple example and classes? Links or articles?
Lets say we have something like -
A user can create multiple posts, and each post has a category [science article, match article] etc in the drop-down and same we need to internationalize drop-down as well.
Two hints:
Read the manual of cakephp.
Look into the code of a available application (maybe croogo)
My open source project is translated.
It call CandyCane. A port of Redmine into CakePHP.
I also imported translation files from Redmine, so CandyCane supports numbers of languages from the beginning.
https://github.com/yandod/candycane
It might be helpful for you.
I've used CakePHP on several projects in the past, and have more recently started using Ruby on Rails, but there's a new project I'm about to start that will require PHP. While refreshing myself on CakePHP I learned that there is a new framework called Lithium that is essentially what CakePHP 3 was going to be. It's being developed by a group of former core CakePHP devs.
I haven't found a whole lot of information about it since it's still under development status, but I was wondering if anyone knows (or has a link to) some information on what benefits it provides over CakePHP. Hopefully something a bit beyond the quick overview shown on the official site. I'm trying to decide whether to use CakePHP for my upcoming PHP project or to wait a bit for Lithium to release a non-development version and try that out.
Hope this answer doesn't come too late, (and as the lead developer of Lithium, I'm a little biased :-)), but I will say that this is a hard thing to sum up. Lithium is the culmination of over 4 years' experience building and working with CakePHP, and while it retains many of the same designs and conventions, it was built to correct CakePHP's many architectural flaws.
In brief:
Framework features are grouped into loosely-coupled "packages" that are easy to use independently.
Tangentially, everything in Lithium is a "library", including your application, and Lithium itself. Support for integrating 3rd-party libraries is vastly improved, and all classes are namespaced, so you can finally have a model called File.
It is very easy to swap out core classes with your own custom implementations.
Lithium has a unique "filter" system that allows you to hook into many methods in the framework, which allows you to design your applications in an aspect-oriented fashion. These features work together to make Lithium the most flexible PHP framework, bar none.
Everything is lazy-loaded, and the architecture has been designed for maximum performance.
Lithium supports the latest tech, especially new databases like CouchDB and MongoDB.
I could go on for a while, but that's the gist of it. If you have any more questions, feel free to drop by #li3 on Freenode, and someone will happily give you a tour.
There is very little documentation so far. Here are some brand-new slides from gwoo though, that might be a good overview:
http://www.slideshare.net/gwoo/li3-ocphp
See the Lithium about page in their wiki. It lists all the features it will provide.
http://rad-dev.org/lithium/wiki/about
I was trying develop a website with Cakephp and Joomla... But lately I've been founding a lot of barriers that create difficulties implementing things that would have been a lot easier if I only developped using one of the components.
So, in your point of view (as someone with more experience than me), is it worth to integrate CakePhp with a CMS?
If yes, what do you think its the best and easier CMS to integrate with?
Or use Croogo (http://croogo.org/)
A CakePHP CMS. I like Croogo's implementation more than Wildflower and the admin UI looks a bit similar to Wordpress.
From my point of view i wouldn't try. I think there would be a lot of crossover functionality and a lot of conflict. Either use Cake and write a CMS and the other elements you want or pick a CMS and develop the other elements you want as add-ins/plugins.
Joomla, Drupal, Xaraya, Expression-engine etc are all extensible so pick the one that is the best fit and has the ability to be extended or maybe already has plugins you require.
Another option would be to use Joomla as the CMS and Cake for the other element you want, keep them as separate entities but skin then identically and make the navigation seamless. In this case about the only thing you would need to integrate would be state.
There are some out there already that are on Cake from the ground up. Wildflower for example
http://wf.klevo.sk/
I have a cakephp site that is running wordpress in it's public_html/blog folder and it is doing great.
They are basically two separate sites, with two separate backend but it is fairly easy to create a model for the wordpress database if you want to pull in any data (eg. posts, pages, comments) and use it in the cakephp site.
As far a integrating the two I don't think it is a good idea if it needs to be a seamless experience for the backend users, most frontend users won't notice the difference because you can use the same style sheet and images.
If you want any more about my experiences with the combination let me know!
Cakeui is a rip of Croogo. Infinitas CMS could be what you're looking for if you want a full blown application or check this site for a list of good CakePHP Cms
As the developer of Croogo, I will be biased and recommend you to check it out at http://croogo.org. It comes with a web based installer too and you should be up and running in minutes.
Another CakePHP based CMS is Infinitas which has more features (including shopping cart). Both are based on the latest version of the framework (1.3 at the moment) and are actively developed.
I wrote a lot of CMS type apps with Cake and was thinking along the same lines. I've tried Joomla, Drupal and Wordpress but still had a dirty feeling in my mouth that I was failing by using Cake just for the sake of it or vice versa.
The most important common denominator, in my experience, is the back-end. It is re-used most often, but gets the least input.
Now I have built my own CMS with CakePHP. The intention is to 'opensource' it, but it's not quite ready yet.
I don't think it is worth the headache trying to combine, then maintain Cake and a 3rd party CMS. Save your best modules and components and build your own. The blog tutorial will give you a good head start and you can cherrypick what you like from other sources, rewriting it to suit your ideals. The benefit is you will then know the CMS inside out and have it working just the way you want. You'll learn a lot along the way as well.