Using Django 1.7
django-cms 3.0.9
djangocms-text-ckeditor 2.4.3
manage.py migrate djangocms_text_ckeditor gives an improperly configured error:
https://gist.github.com/e7c754d329eb22126b11
http://django-cms.readthedocs.org/en/latest/upgrade/3.0.html - suggests there is work to do, but doesn't indicate what needs to be done to get it to work.
The gist is not accessible.
Anyway, have you had a loot at http://django-cms.readthedocs.org/en/latest/upgrade/3.0.6.html#django-1-7-support and https://github.com/divio/djangocms-text-ckeditor#installation?
You must customize some settings to setup django CMS 3.0.x on Django 1.7
I commented out all the CMS applications. got everything else working correctly. And then added the applications back. It began working correctly after that. No setting problem, no application order problem. Weird.
Related
I am trying to debug a Twig template in my Drupal 9 site. I am using VSCode as my IDE and using Xdebug for debugging. I have setup/configured the installation based on the instructions outlined here -
https://www.drupal.org/docs/develop/development-tools/configuring-visual-studio-code
I am able to set breakpoints in PHP files (step thru and watch variables successfully) however I just can't seem to do the same for Twig template files (just so I can see what variables I have access to in that template). What I mean by when I say I am unable to add the breakpoint is that clicking on the gutters of a Twig file within VSCode does not result in addition of any breakpoint.
I'd like to take advantage of Xdebug instead of using debugging functions like breakpoint() and dump() offered by the Devel and Twig_xdebug modules within Drupal. I am pretty sure I am doing something wrong or have missed a step but I can't seem to figure out what it is.
Some more details on my env:
a local Drupal 9 setup on a Mac OS that uses PHP 7.4 and nginx as its webserver.
Xdebug (v3.1.1) is installed and enabled (verified via phpinfo() output)
VSCode (1.63.0) installed with all of the supporting Drupal and PHP extensions outlined in the above article (specifically php-debug) have been installed.
I am using the default launch configuration to Run my debug session in VSCode.
I'd appreciate any pointers on what I am doing wrong and/or what I can try. Also, I hope I provided enough info on my use case.
Twig compiles the template files into PHP files. You need to set breakpoints in these Twig generated PHP files in order to debug them.
On this page, I also see that there is caching involved, which you will need to disable. That documentation seems to be quite comprehensive.
Came here looking for an answer to this very question.
You may be interested to know that there are a couple of ways to achieve this. You can either use a built-in feature of the devel.module (see: https://www.drupal.org/node/2788089) or there is also a contrib module called twig_xdebug, which lives here: https://www.drupal.org/project/twig_xdebug
I think the mechanism behind both of these is probably very similar, to be honest. The latter of those links provides further links to several guides on the subject matter. HTH! :)
I upgrade a Plone site from 4.2 to 4.3. The upgrade steps are basically:
running install.sh to have a 4.3 environment
copy Data.fs to var/filestorage and custom dexterity package to src
running upgrade in ZMI
Everything seems fine. But when I add/edit Page items, TinyMCE toolbar is missing for the body field. Only showing a Text Format dropdown. Note: I do see the toolbar trying to render (first 2 icons appear), but fail and disappear.
What am I missing? Any hints?
No definitive answers, but a few suggestions. I have 9 plone sites all running the same version of Plone (4.2) and have some where TinyMCE works flawlessly, and others where I can't make it work at all.
Check /portal_javascripts and make sure that you have ++resource++plone.app.jquery.js (I think you also need jquery-integration.js and ++resource++plone.app.jquerytools.js, but I may be wrong about those), as well as tiny_mce.js and tiny_mce_init.js).
check /portal_kss and ensure you have ++resource++tinymce.kss/tinymce.kss
check /portal_css for ++resource++tinymce.stylesheets/tinymce.css
I saw your edit about the toolbar beginning to display after I posted this response. You really need to use the development tools for your browser-of-choice (e.g. Firebug) and look at the console. If it starts to display and then fails to finish, there's sure to be an error in the console log.
Check to see whether you have outstanding upgrades to the Products.TinyMCE:TinyMCE profile in Upgrades in portal_setup via the ZMI. If there are any, run them and restart your Plone instance.
I had the same issue with the same version upgrades and there were outstanding upgrades. They must have been missed somehow, presumably a bug in the Plone upgrade process from 4.2.5 to 4.3.4.
FWIW, I just ran into this issue in an upgrade from 4.1 to 4.3.14.
In my case, the problem was that the site uses the Plone Classic skin instead of Sunburst. The Classic skin for some reason did not have the tinymce layer registered. The giveaway was that jquery.tinymce.js was registered in portal_javascripts, but marked in orange as (resource not found or not accessible). I grepped the buildout eggs and realized that jquery.tinymce.js lives in a skin layer of Products.TinyMCE-1.3.26. From there it was easy to figure out why it was not found.
I am following the first method for overriding templates discussed in the docs.
It is working on my development server, but for some reason it's not working on my production server (in any environment). The template file I created in app/Resources/FOSUserBundle/views/Security/login.html.twig simply has no effect.
My dev server is windows and prod server is linux. It seems to me that it must be related to the install of the friendsofsymfony bundle itself. Why else would it not be picking up the template?
It was naming/namespaces, somewhere down the line.
I've encountered the same problem.
Locally i work on OSX and remotely on linux.
The path must be on linux app/Resources/FOSUserBundle/ not app/Resources/FosUserBundle/
I have a site running in DNN 6.0 . I upgrade the DNN verion 7. After Upgrade the Design the site is totally messup can any one give me the idea how to Update the DNN to verion 7.
Thanks
It's not necessary that the upgrade went wrong.
Maybe some of the modules you are using are incompatible with DNN7 or you have changed some of the core pages or styles.
It's hard to give a more precise answer since 'totally messed up' doesn't really say what's the problem
Posting the stack trace or error message would help a lot if you want a useful answer.
Often 'totally messed up' is due to a dll version issue.
On a side note, I hope that you have backed up both the database and website files before you upgraded the site. If you have added 3rd party modules, check their compatibility with DNN 7.
I had this problem too, you need to basically update the skins to use Gravity (or some other half-decent skin besides DarkKnight) - right now, it is probably using the old DarkKnight skin (I would guess) and I've seen a lot of issues trying to use DarkKnight in DNN 7.x.x.
Try this:
1.) Admin\Site Settings\Basic Settings\Appearance
2.) Set Site Theme\Container and Edit Theme\Container to Gravity (anything but DarkKnight)
3.) Host\Host Settings\Basic Settings\Appearnace
4.) Set Host Theme\Container and Edit Theme Container to Gravity (anything but DarkKnight)
I developed a website in wordpress and used several plugins. One of the plugin was http://wordpress.org/extend/plugins/background-manager/
Every thing was working fine on my machine. But as i get uploaded it to client server. the whole site stuck due to lower version of PHP. This plugin requires PHP 5.3 and on server we have PHP 5.2. Since its a shared server, we can't upgrade its PHP.
Then i look into the code of this plugin it was using PHP 5.3 feature namespaces. Is there any way to downgrade this plugin that it will work with PHP 5.2?
This is a really tricky problem, and of course, it's really, really bad practice to use old code for plugins as they may have fixed security vulnerabilities or other serious problems. It would be better for you to move the site to a server with more up to date PHP.
Having given that important warning, you can, however, browse to the tags directory in the plugin repository and extract the files you want for the previous version. Plugin history is public and always maintained.
For instance, for the plugin you mentioned, you can visit the SVN part of the plugin repository at:
http://plugins.svn.wordpress.org/background-manager/
You'll find the previous versions there under the "tags" folder, named after their versions.