I want to migrate existing news from one instance to another one incl. relations to FAL and content elements.
What is the best practise? I tried T3D Export, but it needs too much memory. Is this the only solution or do you have better ones?
1st you can try to export smaller chunks.
2nd you can do the export by hand. But then you must know which records are involved and what files are involved. And you must handle uid-collisions!
Starting with a simple query for your news-records.
Then you need all related records: FAL, tt_content, categories
Depending on your tt_content records you might need further related records - typical: FAL
Then you need to identify all the files.
Before you import all the records: make sure the used uids are unused in your target installation. oherwise you need to modify your uids (e.g.: you can add a constant value of 10000 to all your uids)
Related
My apologies in advance if this question has already been asked, if so I cannot find it.
So, I have this huge data base divided by country where I need to import from each country data base individually and then, in Power Query, append the queries as one.
When I imported the US files, the Power Query automatically generated a Transform File folder with 4 helper queries:
Then I just duplicated the query US - Sales and named it as UK - Sales pointing it to the UK sales folder:
The Transform File folder didn't duplicate, though.
Everything seems to be working just fine right now, however I'd like to know if this could be problem in the near future, because I still have several countries to go. Should I manually import new queries as new connections instead of just duplicating them or it just doesn't matter?
Many thanks!
The Transform Files Folder group contains the code that is called to transform a list of files. It is re-usable code. You can see the Sample File, which serves as the template for the transform actions.
As long as the file that is arrived at for the Sample File has the same structure as the files that you are feeding into the command, then you can use any query with any list of files.
One thing you need to make sure is that the Sample File is not removed from your data source. You may want to create a new dummy file just for that purpose, make sure it won't be deleted, and then point the Sample File query to pull just that file.
The Transform Helper Queries are special queries that you may edit the queries, but you cannot delete and recreate your own manually. They are automatically created by PQ when combining list of contents and are inherently linked to the parent query.
That said, you cannot replicate them, and must use the Combine function provided by PQ to create the helper queries.
You may however, avoid duplicating the queries, instead replicate your steps in the parent query, and use table union to join the list before combining the contents with the same helper queries.
I am creating a data dictionary and I am supposed to track the location of any used field in a workbook. For example (superstore sample data), I need to specify which sheets/dashboards have the [sub-category] field.
My dataset has hundreds of measures/dimensions/calc fields, so it's incredibly time exhaustive to click into every single sheet/dashboard just to see if a field exists in there, so is there a quicker way to do this?
One robust, but not free, approach is to use Tableau's Data Catalog which is part of the Tableau Server Data Management Add-On
Another option is to build your own cross reference - You could start with Chris Gerrard's ruby libraries described in the article http://tableaufriction.blogspot.com/2018/09/documenting-dashboards-and-their.html
What is the best way to allow backend users to edit variables?
For example, I have a TYPO3 that sends out various e-Mail notifications and I want the backend users to be able to globally change the recipients. I started with template constants, until I found out, that backend users cannot edit the "template" module.
So what would be the best way to achieve this? I'm using Typo3 8.7.7
I would create a configuration record which can be edited by the backend users.
one way would be to include one file from fileadmin/ into the constants definition of typoscript. This file editors could change. But that could be a security risk, as the editors could define any constants.
the next option would be to define additional fields to the pages record, where these values could be set by any editor. In typoscript you access the field (maybe with slide = -1, so the value needs to be set just once)
another option: add these fields to a (special?) CE (ContentElement).
last option: use std CEs (e.g.HTML-content) at special pages or columns and use the content field (bodytext). (HTML-content has the advantage that the bodytext field is stored unmodified.)
Cleanest and leanest option would be option two (additional fields to table 'pages'). Option three and four are possible with pure typoscript, but you need to use CONTENT or RECORD object. If you use fix uids: remember that your editors might delete the CE and add a new CE with the same content (but another uid)
Addition:
As #Thomas-Löffler in his answer said:
you also can add a new kind of record/table, where an editor can insert or change the global values. Handling is like pages or tt_content. you can differ if your records are global (pid = 0, or special storage page) or dependent on page tree (rootpath), so you can have differnt values for different page subtrees.
I like Thomas‘ answer for providing a dedicated place to store the configuration option instead of putting it e.g. to pages because your configuration option is not bound to a page context.
Nonetheless for me personally it feels a bit odd to create a dedicated table for it. A table that would never hold more than one record.
That leads me to the conclusion that a key-value storage would be the right thing to use. Fortunately, TYPO3 ships System Registry. The only downside is that there‘s no interface for it so you‘d have to come up with your own forms to fill it. That‘s much easier if you go with Thomas‘ solution…
A clean and easy way is setting up a backend module with a form to set the email addresses.
Then you can grant the access right to a specific group or user and they are ready to go.
I should create a new pdf , for example a offer. At the end of the new pdf i have to import several existing pdfs, these pdf has form fields and i must fill up this fields.
One problem is that the different existing PDF has all the same form fields e.g txtNAME.
Is there a possibility to add existing PDF in a open document and fill up formfields directly?
Thank for help or ideas
Just keep in mind that fields with the same name will have the same value.
This can be a boon (if you did some thinking ahead when you planned the forms), but it also can be a hindrance.
One possibility you may have, if the number different additional pages is not too high: You might prepare a "master form", which contains the subsequent pages as hidden Templates, and then when you create your document, you will spawn the according pages with the option to make unique field names.
Im using a Page (type Folder) to show all records with this pid. Is it possible group these records somehow? Theres a field in my DB called "vid", which contains the uid of some other records. I want the records in my folder to be grouped by this uid. Any suggestions? (Using Typo3 4.6.3)
Ok, then the simple answer is No. Grouping is not possible with the default backend list view module. You can sort, and search/filter there, but not more. You may write a custom backend module that does the trick for you.
What I could also imagine is to use the export function in the list module (there is a button somewhere) and then do the grouping with your favorite spreadsheet tool (like excel). Depending on how often you need this feature that may be a simple workaround that does not require and additional coding.