while working on my basic website and creating a custom plugin to add different taxonomies and custom post types, I ended up with several entries in the database that are not useful anymore.
I'm wondering if there's a nice way of deleting them.
Using plugins to clean up the database doesn't work, because these search for orphaned contents. But these taxonomies do exist along with their terms, and I guess there is no reason to consider them orphaned.
They were created with "register_taxonomy" and afterwards added the terms manually.
Thanks a lot!
Related
I have recently taken up salesforce.com and i have very little idea about its workings and stuff. Recently i was going through some of the stuff and i had a doubt...
Is there any way through which i can find out where an particular field/ object/ visualforce page has been used in an application. For example lets say i have a field labeled Sales, i want to be able to find where that particular field is used, under which object, and the object in which visualforce page/ Apex class, and the visualforce page/ Apex class is used in which application.
Hope i have made my Q clear.
Thanking everyone for their help
It's not really a programming question, you might be better off asking about administrative stuff like that on salesforce.stackexchange.com.
If you have a test environment (sandbox) - you could always try deleting the field there ;) I'm kidding but if you'll try it the page should display you a list where the field is being used.
Similar thing could be achieved by creating a changeset, adding that field to it and then checking dependencies.
But probably the best way would require some preparations upfront. Read about Force.com IDE (or Eclipse IDE) and how to use it to download files that represent your object definitions, page layouts, classes, visualforce pages, reports... This is great as backup but also will let you search the files (Ctrl+H in Eclipse or just use whatever you want once you have the files locally). Search for API name of the field (similar to My_Custom_Field__c should be most effective.
Pretty old thread but adding another option. I have a free and open source app that scans the fields in your Org and returns the components it's used in (Workflows, Processes, Page Layouts, Apex etc).
Keep in mind that returning fields in Apex and VF is not 100% accurate, as a field with the same API name on different objects would return as being found in a class, even though it might not (as others have mentioned).
Also, it can take quite a while to run on large Orgs.
App: http://schemalister.herokuapp.com/
Source Code: https://github.com/benedwards44/schemalister
I'm trying to make a custom column (for a custom list), where the users can upload files without overwriting the previous - this way they can keep past versions of the files and upload newer ones and the new ones append. There already exist "append only" comment columns and file upload columns that I can see.
I'm working with Sharepoint designer 2007 (2010 doesn't work with the site), and I'm referencing this code I found online somewhere (http://pastebin.com/raw.php?i=0qN89meu), trying to research the Sharepoint documentation on MSDN. I can open the site in designer, but don't know where to go from there (it's already running on a web server, not opening it locally).
I'm just not clear on how to start, I thought there'd be a simple "right+click -> new column" feature but I can't find it. If someone could point me in the right direction to where I could start creating columns on the site, that would be great. Thanks!
An untested idea :
Create a document library with a lookup column to the custom list.
Create an event receiver (ItemAdded and ItemUpdated) than will take the attached files and move them to the other list (with the correct lookup value). --> Code with Visual Studio
Grant to this document library only read permissions.
Adapt the view to display the related documents in the dispform of the custom list.
Advantages:
this seems to answer to your need
you gain all the usability of a document library (nothing prevent you to grant edit rights to other users, force check out, etc.)
Disadvantages:
you have to play with lookup. Can be tricky sometimes, if you play with features
you split one business entity to two entities. You will have to deal with cascading delete (if you need it).
My company has a handful of apps that we deploy in the websites we build. Recently a very old app needed to be included along side a newer app and there was a conflict w/ a duplicate table name needed to be used by both apps.
We are now in the process of updating an old app and there will be some DB updates. I'm curious what people consider best practice (or how do you do it) to help ensure these name collisions don't happen.
I've looked at schema's but not sure if thats the right path we want to take. As the documentation prescribes, I don't want to "wire" a particular schema name into an application and if I add schema's to the user search path how would it know which table I was referring to if two schema's have the same table name. although, maybe I'm reading to much into this.
Any insights or words of wisdom would be greatly appreciated!
Postgres has namespaces which is definately the most efficient way of handling that sort of thing :)
Just create a new namespace for the old database and you're done. The way most PHP/MySQL solutions solve it (specific prefix per app) is also an option, but not one I'd recommend.
[edit]Specifically, you can call your tables like this the_namespace.tablename besides changing the search_path. For the rest, the search_path will decide your namespace if you don't add the namespace.
I am working on a Drupal site with a few friends. Obviously we can Version control the code... but what do we do to keep each others databases in check?
I have managed to get all the theming into files (contemplate etc), but ideally my views settings, menu settings would be in line also... (Not worried about Content either way as we're just building the framework)
Any suggestions?
Using Features along with Context is very powerful. Context lets you create a "section" for your site. It's best illustrated through an example:
Lets say we define the "Forum" context as anything with the url of forums/*. Context lets us say: "I want to show these three views in the right side bar, only when I am in the "Forums" context.
Now, using Features, we can create "module" define by the context. So, we will end up with a module called "youSite_forums", which will include all the views, blocks, etc. that was define in your Forums context. It also will determine the correct dependencies, as well as Content Types used in the context. All will be bundled up nicely in a module.
As for versioning content such as node, you can user either Node Export, or just do a DB dump using Backup and Migrate. We use these occasionally, but we never have every node versioned in SVN.
Links:
Features
Context
Backup and Migrate
Problem Solutions in Database Migration from Development to Live Sites
You can find some more opinions on this here: Drupal DATABASE deployment strategies?
We currently use an SVN repository to ensure everyone's local environments are kept up-to-date. However, Drupal website development is somewhat trickier in that any custom code you write (for instance, PHP code written for a node body) is stored in the DB and the changes aren't recognized by the SVN working copy.
There are a couple of developers who are presently working on the same area of a Drupal site, but we're uncertain about how to best merge our local Drupal database changes together. Committing patches of database dumps seem clumsy at best and is most likely inefficient and error-prone for this purpose.
Any suggestions about how to approach this issue is appreciated!
Unfortunately, database deployment/update is one of Drupals weak spots. See this question & answers as well as this one for some suggestions on how to deal with it.
As for CCK, you could find some hints here.
As for php code in content, I agree with googletorp in that you should avoid doing this. However, if for some reason you absolutely have to do it, you could try to reduce the code to a simple function call. Thus you'd have the function itself in a module (and this would be tracked via SVN). But then you are only a little step from removing the need for the inline code anyways ...
If you are putting php code into your database then you are doing it wrong. Some stuff are inside the database like views and cck fields plus some settings. But if you put php code inside the node body you are creating a big code maintenance problem. You should really use the API and hooks instead. Create modules instead of ugly hacks with eval etc.
All that has been said above is true and good advice.. To answer your practical question, there are a number of recent modules that you could use to transport the changes done by the various developers.
The "Features" modules is a cure the the described issue of Drupal often providing nice features, albeit storing lots of configs and structure in the DB. This module enables you to capture a feature and output it as a pseudo-module (qualifies as a module with .info and code-files and all). Here is how it works:
Select functionality/feature to export
The module analyses the modules, files, DB content that is required to rebuild that feature elsewhere
The module creates a pseudo-module that contains the instructions in #3 and outputs everything (even SQL to rebuild the stuff in the DB) into a module package (as well as sets dependencies for other modules required)
Install the pseudo-module on your new site and enable it
The pseudo-module replicates the feature you exported rebuilding DB data and all
And you can tell your boss you did it all manually with razor focus to avoid even 1 error ;)
I hope this helps - http://drupal.org/project/features
By committing patches of database dumps, do you mean taking an entire extract of the db and committing it after each change?
How about a master copy of the database? Extract all tables, views, sps, etc... into individual files, put them into svn and do your merge edits on the individual objects?