While firing a query in DB, No matter you pass "Open" or "open". Both are same.
Your first question's answer is: As per EE Standards, It should be "open".
EE save "open/closed" in database, it shows in list page after making "first letter" capitalized.
Simply put, if you value your time even a little bit, I would use DataGrab rather than rolling your own import / export routines. Datagrab is simple and it works.
The 'updating existing entries' option in datagrab works OK - but is not perfect: it depends on your data quality and which field you set as the reference etc. As ever with these sorts of things,...
From the Developer:
Use a slash ‘/‘ to separate subcategories, so you can do something like, 'Category / SubCategory'
The delimiter is hard-coded but if you want to change it is around line 1420 of models/datagrab_model.php:
$delim_cats = explode('/', $cat);
It really all depends on what field you're ultimately going to import into. If you're importing into an XML-formatted textarea or a Rich Text Editor field, then you'll need to totally remove both the <p> and <br> tags, because EE adds those tags dynamically when inserting the content into the template, and, as you said, replace them with carriage ...
EE's built in Member Importer can be a bit fickle from time to time and the error reporting is.... well it is anything but useful. So I have a list of things that you can try
Upload the file to the root of your server and try both ../member-import.xml or member-import.xml I have had various results depending on the server environment.
EE requires username, ...
I've been using DataGrab for the same thing. As of the current version, only Store 1 is supported, however, it's fairly easy to modify the Store datatype to support Store 2.
Once you set up the import in DataGrab, it provides you a URL which you can hit with cron to regularly import updates.
I have ended up going with the following plugin found on devot-ee
Weblog Entries Exporter
Seemed to do the trick. Specifically for ExpressionEnginev1 it gives the option of exporting as a .CSV or .XML. Just what I needed
Had to submit a support ticket over at Solspace and got help right away. Solution was to set the Unique Field setting to something other than member_id and the import worked beautifully. Big thanks to Nicolas Bottari. :D
I think you should try to narrow down the error a little more. Cut the list in half and try each half individually. Does one half go through and the other error? Put aside the working half and cut the bad half into two, and do it again. Keep doing this until you get either a specific XML node causing the issue or figure out it's more about quantity. (You'd ...
DataGrab and Solspace Importer add-ons can both import various types of data into EE, such as CSV, XML, etc that can be exported from FileMaker.
I would look at both of these add-ons and work out which one is best suited to your needs based on the complexity of your source data.
For data import, I highly recommend using AJW datagrab with CSV data.
data export is a little bit trickier, but you can setup a template to output to CSV/XML or you can use a plugin like Zenbu Studios Hokoku to setup exports directly from the admin CP (if you use Zenbu).
If you want to setup CSV output and ...
If you are using a normal, EE checkbox, you should just need to supply pipe-delimited values (eg, One|Two|Three).
If you are using a Field Pack checkbox, these aren't currently supported within Matrix fields, but I can add it pretty easily if you need it.
Figured it out. Posting here to help others in the same spot.
I had the batch field set to 500/batch, since we did huge imports at the start. Got the problem when we started importing <500 I guess.
So, I removed the 500 from the input field, and now it works like it's supposed to.
Data Grab does support category importing (See configuration grab) but as part of entry import (as far as I'm aware), so possibly discard entry information after import if it's not needed...? You could also possibly have all the categories imported with 1 entry?
If a category already exists, it won't create a new one but utilise that one.
By accident I ...
There's no silver bullet unfortunately. I'd bring in the latest site to local. Upgrade local to V3. On local create/rename fields but don't delete.
Document every change to the channels & fields because once your local setup is ready you will have to set live to offline.
Then update to EE3 then update all channels & fields to match local. Then ...
There are a couple of add-ons for importing data that you could look at. I imagine you'd need some further customization though to scoop up that format.
Yes, that is a sound approach. Create a Channel for your your government agencies with the necessary Custom Fields to hold data. Then use a data import module to map the data to appropriate Channel Fields and import the records as Channel entries. There are two good add-ons for this: DataGrab and Importer.
If you run into issues with running out of PHP ...
All files in asset fields are stored in a bunch of the exp_assets_* tables. You can insert/delete/update rows to make the changes you want. For instance, you can add new files to exp_assets_files, and update rows in exp_assets_entries and/or exp_assets_selections to make the assignments to entries.
Alternatively, you can include PATH_THIRD . "/assets/...
One option you could try is to convert the HTML to Markdown format and import that into a MarkItUp or Markdown formatted text field.
Brett Terpstra's online Markdownifier tool (http://heckyesmarkdown.com) can be scripted and Brett has a Ruby script (https://gist.github.com/ttscoff/2960951) that you can use to call it.
I've successfully used this before by ...
and maybe exp_channel_entries_autosave
Should get you there. Obviously back it all up first in case it goes horribly wrong.
You may also be to approach it the other way and install the add-on on the staging server and get them in synch that way. There may well be much less data to deal with.
OK...progress, enough progress to be able to post an answer anyway. Turns out using Datagrab rather than Importer seemed to do the trick. Why that would make any difference whatsoever is beyond me as they're both great EE plugins. I'm open to suggestions on that one
So, in a nutshell, I created the Image field in the new site using File as its field type. I ...
Try the "Loose XML" option.
Also run your xml through a validator just to make sure it's clean.
You might also be missing the XML header in your XML file, eg. <?xml version="1.0" encoding="UTF-8"?>
Finally, the <categories></categories> node should contain a string of category data, such as a comma-separated list of category names.
At a quick guess, I'd try the following (backup and do it all on local ideally)
Change the formatting on those original fields from xhtml to 'none'.
On your target install, also set the field formatting from xhtml to 'none'.
After your import, update the fields to be xhtml formatted.
It's not going to help your titles though, titles are put through a ...
As of this writing, Importer does not read XML node attributes, such as lang="es" for example. Therefore, Importer will read only the first node of a series of nodes named exactly the same, <description> in this case.
I recommend submitting this as a Feature Request under the specific add-on category. It'll also give other users the option to vote up ...
The 'relationship' is the entry_id. So if you can import the default language, grab the entry id, then import the translated entry and assign the same entry_id it should work. I'm not sure DataGrab would do that out of the box.
Use DataGrab -- http://devot-ee.com/add-ons/datagrab -- and import with a spreadsheet. If you have only one level for categories, it's super easy. If you have category levels or categories with same name, it's a little more complicated.
If you have levels, your spreadsheet (csv is best, IMO) can be created safely following these steps.
In EE, create the ...