I am trying to implement the Features module on one of my Drupal 7 sites for managing blocks. I have a couple questions though. 1st, when you create a new feature on the source site, do you then take that newly created feature and put it in your modules directory and enable it on the source server AND the destination server or JUST the destination server?
Also, I'm wondering how it works when you are trying to manage blocks with a test server and a live server when the live server is a clone of test. In other words we create a test server, construct our site including content and blocks and when it's finished we clone test to live. Then we install the features module on test and create a feature that contains ALL of our custom blocks. When I did this though and moved that feature to the live server and enabled it, it was immediately in an overridden state. Are features only meant for moving NEW blocks from one site to another and not meant to manage blocks that already exist on BOTH servers? Should I create the feature containing all the blocks on the test server and then delete the blocks on the live server and THEN enable the feature on live which would populate the blocks on live. I'm just not sure if I'm missing something or going about this the wrong way.
THANKS
UPDATE: OK, I'm pulling my hair out over here. Again, so I have two sites a source and a destination. The destination was is an exact clone of the source. I have three blocks on both sites that I would like to manage via features. SO, on the source site, I decided to test with just ONE block first. I first edited the block so it would be different than the one on the destination site. I then created the feature including the block and block settings (by the way I'm using Features Extra to accomplish this) and then I place the feature on the destination site and when I activate the feature, the feature is actually NOT in an overridden state and the changes that I made to the block on the source site, show up on the destination site no problem. HOWEVER, if I try to add the other two blocks now to this feature on the source site and recreate it and export it out to the destination site, the feature on the destination site is now in an overridden state which is fine, but no matter how many times I "Revert" the feature to take the blocks out of the dB and into code, it will NOT get out of an overridden state. I have flushed the cache, disabled the feature and re-enabled, and tried reverting and it is stuck as overridden and I do not see the changes to the other two blocks that I made. I then thought maybe it's because I am doing three blocks at once. I then took JUST block number two by itself and created a feature for it and put it on the destination site and it gets stuck in overridden status. Same goes for block number 3. Block number one by itself is fine and does not get stuck in overridden status. It's just block number 2 and three. As far as I can tell all three blocks were created the same exact way and do not have any different settings as far as roles, pages etc. I am stumped on this one for sure.
comment doesn't allow this much log post, so posting as answer.
I can't say much without having exact problem. But This is how features works. You have to do changes in a source site. then create feature of that changes. Now On destination site you have to enable that feature. If you already have that changes in destination site, than feature will be overridden, you revert it and get changes.
As you saying you added two other blocks in feature, but you didn't change anything in those blocks, so they are already in destination site. that why features in overridden state. when you revert It does changes, but sometime it doesn't changes state on (admin/structure/features/).
I don't know your exact requirement, but I think you should change do changes in source site and then pick them in feature and enable on destination site.
Related
I have downloaded an Umbraco 6 site and I have tried replicating the environment locally in my machine, using the production database and the compiled site from production.
If I go to the Umbraco backoffce and to the Settings => Dictionary entries, I can see a specific dictionary entry in multiple languages.
This entry is displayed correctly in production when the user chooses a different language. However, locally, when I change the language, the dictionary item still appears in english (the default language and does not get translated).
I have tried running the site through Visual Studio and WebMatrix, to check if this was some issue with the webserver settings locally, as this might be session related, but the issue still happens.
Is there a reason why translation for dictionary items is not working as expected? Content that is created through nodes and translated there is showing up in the correct language, but dictionary items are not.
UPDATE
I am now looking into something that could be responsible for this. When I am at the content area and select one of the language nodes and head to properties, I see multiple "Alternative links", which contain URLs to the same page on different domains. I don't see localhost:XXXX/EN.aspx there, which makes me wonder as to whether or not the site is handling the language detection correctly in localhost. I haven't found how to add additional links there, and be able to use a wildcard for port would be interesting.
You should right click on the node - select "Culture and Hostnames" and add your domain there.
After that right click on the root "Content" node and click on "Republish entire site" - that should clear the cache and you should be able to see the new url under "Alternative links".
So I am about to add another WP blog, but I'd like to keep it under version control. Then I started thinking, how would that affect my current WP workflow. Based on my limited xp in using WP, when an update is pushed from WP dev team, I see an indication in my admin control panel. From here I can simply click the button, and the changes are implemented behind the scene. This approach is great for a single WP instance outside of version control, but what about more nodes, and in version control?
Some of the WP updates include both code and schema changes, so I can't simply publish the code without also implementing the new schema changes. The best I can figure it is to do the following:
Localize current WP version stored in version control
Download latest (stable) wp files
Extract to local path (created in step 1)
Diff changes (optional)
Commit changes to version control
Log into each server
Put into maintenance mode
Pull latest changes
Implement new schema changes (????)
Test
Take out of maintenance mode
Step 9 is what is tripping me up. Do I do a schema dump from my local (freshly updated) schema, then import that schema for every server (or use provided schema change file if WP included id).
Is there a better approach to this?
---- EDIT 1.20.2014 ----
After further consideration, I wonder if setting up some type of mysql replication would be the way to go? Have one node access with read/write access so it can make changes which are restricted to database only (i.e. de-activating a widget), but have other servers serving up the blog content read from readonly mysql instances which are replicated to. This way only one server is making changes from which the others will pull. During my research I have noticed that some changes like alterations to child theme via functions.php or style.css can be tracked in version control, but other changes like activating/de-activating widgets are purely sql based, which would be impossible to track in version control.
Is there a better approach to this?
Don't touch WP core (do you really need it?)
OR
Hack core only once in order to replace default repository's URL of WP-core with your's and later use system auto-updater with your repository
So I have an umbraco setup with a 'content' root node and then a 'home' node under that. Under the 'home' node is the content and the URLs are the name of those nodes for example I have a 'about u's node under home and it's URL is '/about-us/'
In the case of the 'news' node, below 'about us', its children some times get '/home/about-us/news/title' of the story as the URL, which throws a 404. I can see that this is the URL of the node on the properties tab, but if I republish it it returns to '/about-us/news/title' for a period before returning to the broken link.
I have only seen this behavior on this node, which contains new-item document types. I basically watched the umbraco tv video and created it following along.
It seems to be to be a umbraco bug, but I would really appreciate any help with the issue
In the web.config, there is a setting called umbracoHideTopLevelNodeFromPath. This causes the behavior you are describing when it is set to false. Do you perhaps have multiple people working on the site and publishing different versions of the web.config that have this setting changed?
When publishing a node with the setting set to false, it would add the /home part to the URL. Otherwise, it would leave off the /home.
Once the Umbraco application has started, there are several processes that run on a regular basis (e.g. to check for expired content). It is possible to piggy-back on these by creating a custom class that inherits from umbraco.cms.businesslogic.ApplicationBase. If you have created one that uses the Document.AfterPublish eventhandler then I would check that it is not causing the issue.
I'm assuming that you haven't written one of these though, so the only other thing I can suggest is checking whether it is an installed package that is causing the issue. Have you installed any Umbraco packages? If so, do they have any automated behaviours, like creating folders etc. If so, this may be causing the issue. The author of a package will usually have a website, codeplex project etc. and they will usually have a issue list or blog.
Edit
I've just quickly checked and uBlogsy, one of the plugins you mention exactly this. It has auto moving and sorting of posts. This is described in the release notes. If you are using this tool for creating news pages, then this will be your issue.
I followed obsidian's link in his answer and read about someone else having the same issue. It seems to be traces back to a umbraco.library:NiceUrlFullPath call in the RSS creator that was feeding news items. I replaced the umbraco.library:NiceUrlFullPath calls with umbraco.library:NiceUrl calls and the issue has disappeared.
I currently develop Drupal web sites using its multi-site feature that allows me to have a single code base and support multiple distinct settings per each site.
I set up a dev server and I was quite happy with my arrangement of domains like example.com.local (not that happy because I had to perform a small conversion before entering production, but still quite happy) and the thing used to work well. Too bad I recently started to work at places outside the LAN in which my dev server resides--mostly at clients' places where I need to demo their sites. First of all I set up a dyndns.org account and the server is accessible through the Internet.
Unfortunately the whole domain-based multi-site ungracefully fell down, since I'm now accessing the server via myservername.dyndns.org and Drupal's algorithm takes the domain name into account, so I'm forced to use at least the TLD as part of the directory name (namely sites/local.example.com). So I decided to switch to directory-based multi-site, and now I'm able to access my server from inside the LAN using myservername.local/example.com (having renamed the sites/ subdirectories accordingly). You should easily see why this is suboptimal, since when I browse to myservername.dyndns.org/example.com Drupal looks for sites/org.example.com. I temporarily ended up making a link from sites/org.example.com to sites/local.example.com but again, this does not scale well If and when I'll have to drop dyndns.org for, say, dev.mycorporatesite.com...
Is there any other possibility? I have full access to the server, I can change Apache2's configs, .htaccess and all the stuff.
I would recommend against referencing drupal multisites in folders but instead would set up your server to have a fixed domain name and each site in a subdomain.
So your dev server is at mydevserver.com
and then each site could be
client1.mydevserver.com
client2.mydevserver.com
etc.
If you also at the same time as creating these, you move the files folder from the default to whatever the live site will be i.e.
sites/livesite.com/files
Then when you have to go live, all the references will be correct (if you are drupal 7 this might not be an issue)
The issue: a content editor saves a new content item and gets a 404 on the proper-looking url for the new object. If they then refresh, the item is there, perfectly normal.
This happens for multiple Archetypes-based content types, and we've seen it on at least two different sites. We've seen it on Plone 3.x and 4.0.3. Here's what these sites have in common:
HAProxy load balancing (with and without session affinity)
Multiple ZEO clients
Using either ZODB 3.9.7 or 3.8.4
The issue happens only some of the time, maybe for 1 out of 4 content items
Has anyone seen anything like this?
I do not have an answer for you; this should not really happen. I certainly have not seen this.
You'll need to gather more information to troubleshoot this, and that perhaps requires interactive access to experts, and SO is not the place for such troubleshooting.
All I can do is advice that you gather as much information as possible, including a full trail of the user interaction from the various logs, including HAProxy and the ZEO server.
It may require additional instrumentation at the server level (when the NotFound error occurs, dump additional information about what is present, etc).
Some recomendations/questions:
Verfy that the content object was, indeed, created.
Check that the content views are correct (the ones that are declared in profiles/default/types/yourtype.xml).
Does it happen when adding content directly to plone instance (Without caching and load balancing?
Does it happen when adding content to direct plone instance with load balancing, but without caching? ---> And so on ...?
Maybe not an elegant one, but you might try inserting print statements or pdb breakpoints in the code so you can track whenever a content object was, indeed, created. Do this only as a desperate method of "instrumentation".
Yes. we have recently started seeing the same issue. We have almost the same setup. Haproxy (no session affinity).
I'm wondering since the pattern seems to be haproxy... perhaps its an issue with a request being redistributed after a timeout?
Updated:
We had this issue. It happens when you have a redirect back to the changed object after a save. This is because the 2nd request hits another zeo client which doesn't realise it's out of date.
The only solution we found was a to add temporary session affinity in haproxy (20s) during any POST. Not ideal but does work. I was just searching for a better solution which is why I found this old post.