More efficient ExpressionEngine server moves - expressionengine

I'm trying to find a better way to move my Expression Engine 2 sites from development to live servers. I have a checklist that I go through, starting with running a find and replace for the old/new URLs and server paths, then I update the database config file. This however misses out a huge amount of settings that I then have to go through and change manually, but I don't see why I should need to (unless these are encrypyed somewhere).
For example, I have to change the "Basepath to Template File Directory" in the Global Template Settings manually, along with member settings and a handful of others. There must be a file or entry with these in somewhere that I can change before I upload but I can't find it.
Does anyone know where these are stored?

Those are stored in the database, unless you are using global config variables.
I would highly recommend looking into some sort of config bootstrap. There are quite a few solutions to this, but it's really up to you to pick what's right for your development style / environment(s).
Take a look at the following articles:
http://eeinsider.com/articles/creating-a-robust-config.php-file/
http://boblet.tumblr.com/post/68095239/ee-localhost
http://eeinsider.com/articles/multi-server-setup-for-ee-2/
I've tried those solutions, but in my opinion the best option is NSM config bootstrap.
Check it out here: [http://ee-garage.com/nsm-config-bootstrap][4]
The only thing (currently) missing from these solutions are new config vars regarding file upload paths and locations. You can add those to any of these solutions by adding the variables detailed in this article:
http://expressionengine.com/user_guide/cp/content/files/file_upload_preferences.html#overriding-upload-paths-and-urls-using-configuration-variables

I know I'm late on this one, but for anyone else searching, this plugin is very useful and I have used it on numerous occasions.
ExpressionEngine stores your website URL and Server Path in a ridiculous number of places.
REElocate helps you update these in one simple step.
https://github.com/expressodev/reelocate

Related

Write custom grid layouts with extbase/fluid but without any extension like gridelements

I look for a tutorial, help or an example that tells me what I have to do to write a grid element like 2-colums in basic typo3 (v9) with fluid but no other extension like gridelements, DCE, Templa Voila, etc. I want the same gridelements can do but I dont want to be depended to this extention and move it in my own site extention.
I tried the same with normal content elements (CE) like here:
https://docs.typo3.org/c/typo3/cms-fluid-styled-content/9.5/en-us/AddingYourOwnContentElements/Index.html
But how can I nest a CE in a CE? And how can I do this by drag&drop in the backend?
You can't. The page module doesn't support nesting
You can't nest CEs in a CE. On database level this would mean that you have to make a tt_content record a subrecord of a parent tt_content record. You run into several problems, basically the multilanguage support will be broken and the shortcut element does not function as you will expect it to. That is why the extensions "gridelements" and "mask" exist.
I integrated the gridelements configuration into my sitepackage. So I do not need to bother anymore with it.
Just for your info:
There is now an initiative that works on integrating this functionality into the core (Structured Content Initiative, https://typo3.org/article/a-structured-content-initiative/). Stay tuned to it.
There is nothing special about providing Gridelements via external files, since it's based on TSconfig, TypoScript and Fluid. That's why there is not that much about it in the documentation, since it's the same thing you would do with any other kind of sitepackage. The TSconfig and TypoScript parameters are already explained there, while the Fluid would be up to you anyway.
To have a kind of kickstarter just take any extensions providing Gridelements layouts as an example. A very popular one would be bootstrap_grids, which can be found in the TER or here: https://github.com/laxap/bootstrap_grids
You don't necessarily need the flexform controller of that extension, but the Configuration and Resources folders, show you how to configure stuff and you can see how that is included via ext_localconf.php
There are even comments i.e. in the TSconfig files to explain what is possible there and how to handle i.e. mixed environments with record and file based setups. Although it would be recommended to go for files.
You would at least have to add the necessary backend rendering methods to a draw item hook, that will modify the preview of the container element.
So basically you would have to rewrite everything that DCE, Flux, Gridelements or other similar extensions already do.
Which brings us to the question, why you want to avoid those extensions, since especially those three are well known, widely spread, well supported and available for currently supported TYPO3 versions.

Modx script after package installation

I need to write a plugin that needs to create table in database and some setting from installation form. I can easily create form but I have difficulty to run the script after installation to read options and create table. Is it possible at all to run such simple script or maybe you need to create everything like for example models, vehicles and so on?
I would appreciate if anyone could give me directions how to do it. Modx documentation is not clear about this and https://github.com/splittingred/Doodles/tree/production sample repo contains multiple elements I'm not familiar with and I believe don't need at all
Typically you'd use a resolver to run code after the install.
While in the question comments the setup options are discussed, the package attributes there are actually executed to generate the setup options form, not to process the results.
The docs are a tad dated (mostly the screenshots), but Creating a 3rd party build script explains the different parts of a build script, and what they're for, with a fair bit of examples.
The piece you're looking for is this:
$vehicle->resolve('php',array(
'source' => $sources['resolvers'] . 'setupoptions.resolver.php',
));
You'll need to have a $vehicle (perhaps from a category or other object you're adding to the build) and the file in the provided location. Inside the resolver file you can use $object->xpdo as an instance of the modX class to do your thing.

Use Chef to modify settings for all IIS sites running on a node

our ops team wants to make sure that all IIS web sites are (a) logging to the right place and (b) logging the right things. The most awesome IIS Cookbook allows me to do both of these things if I know what sites are running on this old box, which, sadly, I do not. So a fairly straightforward implementation could be:
list_of_sites.each do |s|
iis_site s do
log_directory 'c:/fireplace'
etc.
end
end
But ... I don't know what sites are running on a given node. Ohai doesn't seem to have this info, but maybe there is a wonderous (I like this spelling better) Ohai plugin that my google-foo couldn't find. I could write an ohai plugin for this I suppose. But it would be my first so a little reluctant to go there. Are there other options?
Good list of ways to list sites is here: Display all sites and bindings in powershell, but not sure how to use a list of sites generated by powershell from within a recipe.
We're running chef 12 and various IIS's but oldest is 7.0.
Thx for any advice!
Making an Ohai plugin for this one thing is probably overkill, I would just use powershell_out with a variant of the code you linked to. You would want something like this:
cmd = powershell_out!(<<-EOH)
# A bunch of PS code goes here
EOH
sites = some_kind_of_parsing(cmd.stdout)
sites.each do |site|
The example PS code you linked is using Format-Table which would suck to parse back out, but I bet you can find some way to output it as JSON which would be much easier, or even just a line-based table without the header lines.

Global variables in apache cocoon piplines

I have some static variables used the XSL which are currently stored in sitemap.xml as global variables.
<map:pipelines>
<map:component-configurations>
<global-variables>
...
</global-variables>
</map:component-configurations>
...
This is all well and good but, some of the variables are deployment specific so need to be changed when the web app starts up. Basically, I need a small number of properties, stored externally to the .WAR to be available in the XSLT.
Has anyone needed to do something similar? If so what approach did you use?
thanks
For reference, it's worth checking out the cocoon input module RequestModule
Why exactly do these properties need to be stored outside of the WAR? Cocoon already keeps plenty of deployment-specific configuration inside WEB-INF.
If you're simply trying to keep the configuration out of the sitemap, .properties files may be your solution. The properties defined in **.properties in WEB-INF are available for use in Cocoon's sitemaps using ${property-name} notation.
Note that my answer is based off my experience with Cocoon 2.1.11; it may work differently in other versions.

ExpressionEngine file manager - default to thumbnail view

At the moment when you go to select an image inside an entry using the EE default file manager, the default view is 'show files as a list'.
Is there a way to show the thumbnail view as the default?
At this point I would be happy with a core hack.
I don't usually use the file manager for sites (much prefer Assets) but this client had a tight budget
I've wondered about doing this in the past as well - turns out it's pretty simple. Open up ee_filebrowser.js and search for the first instance of a("#dir_choice").val(). Immediately after that add this:
; a("#view_type").val('thumb').change();
Make sure you include the leading ;.
I've only tested this in Safari but I can't see why it wouldn't work everywhere. Incidentally, JS beautifier makes this sort of thing infinitely easier.
I don't recommend hacking core for any reason and I suggest it should be avoided at all cost.
With that said, I will provide what I've found out just the same.
Looks like the following files, in EE 2.5.3, are what you'd want to edit:
/themes/javascript/compressed/jquery/plugins/ee_filebrowser.js
/system/expressionengine/libraries/File_field.php
I found these doing a file search in my text editor for view_type which was from the id of that dropdown. The javascript is minified so you'd probably want to un-minify it and then rewrite the part which handles the switch. I'm not the best JS/jQuery person out there, and un-minified js makes it a bit harder too so, I won't offer any more than what I've found so far.
Consider pulling out the parts parts from the two files if you aren't great with js and maybe start a new post tagged accordingly.
Also note: there might be more to this than just those two files so consider this answer a start and nothing more.

Resources