It seems like lots of people are using xdv successfully so this must be something I'm not getting about xdv. I am running 4.0.3 on my local server (Mac). I have a xdv theme running in Plone (diazo.example.com) and I am trying to modify the styles. I can see my changes on apache and DW but they do not appear in Plone. I have debug mode on. I tried deactivating and activating the theme and emptying the cache. No luck, the site does not update. I thought it was 'easy' to make changes on-the-fly with xdv but this has me stumped. I didn't register the stylesheets in CSS registry. Is that a critical step or optional?
On another note, is it worth it to switch to diazo and plone.app.theming? What are the major benefits of doing so?
Thanks!
Elaine
I absolutely recommend that you switch to diazo and plone.app.theming. This is most easily done by starting with Plone 4.1.x instead of Plone 4.0.x. Get a copy at http://plone.org/products/plone/releases/4.1
Then, using buildout, install plone.app.theming. You may have a few issues with lxml, but since you've already done xdv I figure you've conquered that already.
Related
Is there a way to install Plone without Products.Archetypes - not just deactivating - only with Dexterity.
I think there was a way....
plone.app.contenttypes just deactivates the installed Archetypes. Since many packages in Plone 4.3 depend on Products.Archetypes and Products.ATContentTypes, there is no way of getting rid of the package entirely. You could try to uninstall Archetypes in the quickinstaller (ZMI), but I wouldn't expect that to work.
Bottom line is, I don't think it is worth the effort to even try. You wouldn't gain that much and the risk that your Plone site does not work afterwards is very high.
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.
For instance, the yet-to-be-released Twenty Twelve theme is available on GitHub, but it's a Forge build.
And in order to retrieve the actual theme with the normal directory structure, I'd have to install Ruby, RubyGems, Forge and some configuration to go with it.
I am no developer and I just want to use the theme. Is there a way to manually pull out the theme files from the build?
This is what I am thinking:
All the required template, JS and CSS files are in the build directory.
Add html5.js to the javascripts directory inside build directory. Then rename javascripts directory to js (<= compared its directory structure to that on WordPress.com SVN)
Now rename build directory to twentytwelve—the theme is ready.
Is that all, or am I missing the whole point?
PS: I am sure that some of you'd suggest me to download the theme directly from the WP.com SVN repo., but the reason why I don't want to is that on GitHub I can easily track the changes to the theme.
If you really want to just get the latest, ready-to-go version of the theme, use SVN. They push updates over when it's in a stable form, so you don't need to worry so much about whether or not there's broken functions in the version you're grabbing - or any number of weird issues when using an alpha build of the theme.
While that will kind of work, you should really either:
Use the GitHub repository the way it was meant to (clone it, and use Forge to build the theme).
Wait for the theme to actually be released.
While you might be able to extract the theme as-is from the /build directory, there's no real way for you "track the changes to the theme" since the changes will be made in the /source directory. There's no guarantee the committers will build the theme before pushing (which is how the /build directory is currently kept in sync.
Update
If you've been following active development, Twenty Twelve was just rolled into WordPress trunk for the upcoming (late 2012) release of version 3.5:
Changeset 21261
Timestamp: 07/12/12 04:20:46 (14 hours ago)
Author: nacin
Message: The Twenty Twelve for WordPress.
props drewstrojny, lancewillett.
also props corvannoorloos, jeffsebring, kobenland, iandstewart, mfields,
mtdesign, op12no2, philiparthurmoore, sixhours, mamaduka.
So rather than playing around with extracting the theme via GitHub, just use Subversion to check out WordPress trunk and look at the /wp-content/themes/twentytwelve directory.
There's nothing 'easy' about the way you're suggesting going about it. Certainly not easier than installing SVN, pointing it to the repo, and tracking changes there (you know, when they're actually done). It's still version controlled, still easy to see the diff, and still the latest version. Also, note that in github, the theme files do point to /javascripts, so if you're renaming the directory you'll have to manually catch it in the files themselves as well.
If you really want to just get the latest, ready-to-go version of the theme, use SVN. They push updates over when it's in a stable form, so you don't need to worry so much about whether or not there's broken functions in the version you're grabbing - or any number of weird issues when using an alpha build of the theme.
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.
Since this is a beta-1 release, Is there anything which I should especially be worried about?
I've used it for a long time and know several others that have done so without any problems. So I wouldn't be worried if I were you. But I haven't tested all the stuff like SQL queries and other db stuff you can do with drush. But it's really good for downloading modules, disabling/enabling modules, clearing cache and other stuff like that, that you tend to do a lot when developing.
Drush is awesome. It does it's job well. The only thing to be wary of are things like:
Have you modified any contrib modules
yourself?
"Stable" new releases may contain
bug(s) the maintainer did not
catch.
But Drush does provide a backup of contrib modules to /backups.
Drush is pretty safe when it comes to install/uninstall modules or themes (usually it also makes back-ups) but KEEP in mind when you update the core to back-up your entire web site. I have some web sites that I do maintenance and are not build by me that if I run:
drush up
I get weird behavior like: a theme gets deleted (that was the way it was built, I found out that moving the theme from root/themes/themename to root/sites/all/themes/custom/themename fix the problem), or the whole website just stops working (the build contains double code modules folder like: root/modules and root/modules/modules). So in general if your web site is build with best practices, drush is awesome, if not you might run into trouble.