Problem: Within the Content Editor, our web editors with the privileges to edit content as well as publish that content are often forgetting to go to Edit>Approve and Publish, instead they are just saving and trying to press the publish button which publishes to master, but not the live production server. I understand that approve and publish puts the page into the final workflow step, and (atleast on our servers) the publish button does not. I'm wondering if the Publish button can be changed to function as 'Approve and Publish' and whether that will cause any issues for people who have editor privileges but not publishing privileges.
Along those same lines, our admins can save and publish with the publish button without approving by using Edit>Approve and Publish, but they cannot do this with new pages. New pages have to be approved and published once and from that point on they can simply save and then publish with publish button and the content goes live. Is there any way to bypass that initial 'Approve and Publish' step for admins?
I have some experience working in the core as well as editing the workflow, but I apologize if this is a really simple problem, or if I'm missing the point of the way our workflow is setup. I also considered creating an Approve button and putting it next to edit, so that our editors were more likely to remember that step, but I couldn't find an approve command to associate with the new button. I would love some feedback from Sitecore veterans.
Changing the behavior of the publish button is not recommeded and will just end up confusing everyone. Also adding a new button will just lead to more confusion about which button your editors should be using.
Since your editors have to use workflow, they probably don't need access to the standard publish button. Simply removing them from the Sitecore Client Publishing role will make it so they can't see the publish button and therefore have to use the workflow command.
If workflow is turned on, a new version of an item will always be put into the first step of that workflow. You could change that behavior with a handler for the version:added event. If you are only concerned about new items, a processor for the uiAddFromTemplate pipeline could also be used. However, I don't recommend changing this behavior at all. For that matter, I don't recommend using full admin users for content editing at all since you will lose the versioning of your content items. Admin users should be used for administration, not content editing.
Related
I've created a new ASP.NET Web Application for my project. While debugging, Visual Studio is not allowing me to make changes to my code behind (default.aspx.cs).
When I try, I get the "Edit and Continue" dialog letting me know that "Changes are not allowed while code is running or if the option 'Break all processes when one process breaks' is disabled.
but I'm able to edit my default.aspx
Am I missing an option somewhere?
I know exactly what you mean. Turn off "Enable Edit and Continue" setting (in tools->options->debugging->general). Now you can edit .aspx.cs Content while it's debugging on Local IIS.
You are allowed to changes ASPX page because this page is going to be rendered at client side and changes made in page will be directly affected to client browser.
But When you change in CodeBehind visual studio will not allow to change the code because your code needs to be compile again and dll generated to your application needs to be created again with the updated code. That is why it will not allow you to change it.
If you want to change code, you will have to stop the application, change code and run the application again.
If you want to change the value of defined variable at debug time then you can directly change it by moving cursor on it and reassigning value.
Another option to change the value of variable at debug time is from Immediate window.
If you still want to update the code then follow below steps :
Right Click on the Project
Select Properties
Select Web in Right Panel
Check 'Checkbox' at the bottom saying : 'Enable Edit and Continue'
Refer : http://blogs.msdn.com/b/visualstudioalm/archive/2013/06/26/debugging-support-for-64-bit-edit-and-continue-in-visual-studio-2013.aspx
Probably you need to change this when running and debugging multiple projects at the same time:
Break All Processes When One Process Breaks
http://blogs.msdn.com/b/zainnab/archive/2010/10/22/break-all-processes-when-one-process-breaks-vstipdebug0029.aspx
Perhaps yesterday, you was working only with one project and today you are debugging multiple projects. Thats the difference.
Anyway, first answer is good too.
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
When I first created my Plone (4.1) site, I made a mysite.policy add-on to include some custom users and a custom workflow.
I need to make some corrections to both the workflow and the permissions. I updated the src to include these changes, but updating the package in through the Plone add-on manager (uninstall - install) does not work. As soon as I uninstall the status of all my entries switches to "local policy", so I cannot get the fine-grained status setttings back when I reinstall.
Also, the user permissions do not seem to change. Possibly because they were already created at set-up of the site. But I cannot figure out how to code a change to permissions versus a setup of permissions in the rolemap.xml. I assumed that whatever is in that xml is what rules my plone world, but that does not seem to be working.
So far I cannot find anything about this in the manuals and books I have at hand. Any hints how to solve this? Perhaps the only way to go about this is a series of manual changes through ZMI, but it is so much less elegant to do it that wat.
There's plenty of options. I'll try to describe a couple of them.
If your changes include only changes in Generic Setup profile of your site policy (./src/my/site/policy/profile/default/-files) and you don't want to automate the upgrade, you could simply update the profile-files and re-run those specific import steps for your policy:
Open ZMI (site/manage) for your site and look for portal_setup.
Select Import-tab when on portal_setup.
Select the profile of your site policy from Select Profile or Snapshot-list (the title of your profile is defined by the registerProfile-directive in configure.zcml or profiles.zcml of your policy product).
Click to select import steps for Role / Permission Map and Workflow Tool.
From the bottom of the page, deselect Include dependencies.
Click Import selected steps-button.
Go to portal_workflow-tool on ZMI and Update security settings, if your workflow update should modify permission in existing workflow states.
These steps should re-import only the selected import steps of you site policy product's Generic Setup -profile. Re-importing individual steps this way should be quite safe, but be careful: accidental clicks at portal_setup screens may have unpredictable consequences.
These steps can also be automated by defining something called Generic Setup Upgrade Step.
I hope that the default Generic Setup -profile of your site policy product includes metadata.xml with line <version>1</version>.
Update that line to <version>2</version>.
Open the zcml-file with registerProfile-directive and, after it, add
<genericsetup:upgradeDepends
source="1" destination="2" sortkey="1"
title="Upgrade my.site.policy (1 to 2)"
description="Upgrades my.site.policy's default profile from version version 1 to 2."
profile="my.site.policy:default"
import_steps="rolemap workflow"
run_deps="false"
/>
These steps should register such an upgrade step from the profile version 1 to 2, which re-imports steps rolemap and workflow (rolemap.xml and workflows.xml). You should be able to run the upgrade step from the Plone Site Setup's Add-ons-screen, where there should now be an upgrade button after your installed policy product.
As mentioned by #toutpt, the Collective Developer Manual has more examples on upgrade steps. If you have ever wondered, why it's recommended to use integers in metadata.xml, usually independently from the product's release version number', this is the reason :).
Any changes that need upgrade must be shown by increment the number in profile/default/metadata.xml (keep integer). Next you have to write an upgrade step. It will add an upgrade button in the addons control panel.
Please follow this tutorial to learn how to create an upgrade step: http://collective-docs.readthedocs.org/en/latest/components/genericsetup.html?highlight=upgradestep#upgrade-steps
We have a public page on our product service page http://www.facebook.com/realestateagentdirectory?sk=app_171700809577806 that allows anyone to add our "find an agent" app to their own page.
Is there a way to know when FB users install our app on their own FB pages - via page or app insights, or in a different way? Right now we have no clue who/when adds our app to their page.
One way that would work, obviously, (which would be an overkill for this and it would require users to install another app, etc.) is to do this (installing/adding a tab on your page) from within another app which keeps track of all tab additions to other pages.
But we're looking for an easier way of knowing this data. Thanks!
You can track first visit to Page Tab Application canvas via parsing signed_request argument to collect pages who had installed application.
Later you can use FQL table page checking for has_added_app field to ensure tab is installed/removed
I have an ASP.Net website running on IIS7. The developers have created a CMS in the \admin folder, which allows the website admin to create/edit/delete pages.
They have said:
"The read/write permission should be given to the user that requires login access to the admin panel, not the anonymous user that has general public access to the website. The reason for the write permission is to allow the administrator to be able to upload images and files through the CMS, and make various changes to the navigation, style sheet, etc".
Also, they have said:
"Password protect the /admin folder and assign full rights to your admin user as it needs to update data (site files) accordingly as mentioned in the Folder level section above. For certain modules to work, such as the file manager, you would need to use Basic Authentication at the Directory Security level. The FCKeditor folder also should be protected so it has the correct permissions. "
Is this approach safe? I have tried assigning full rights to the Plesk protected folder user (the \admin folder is protected through Plesk), but Plesk keeps reverting back to its default settings. I am told this is a security measure, which makes sense.
What would an alternate way of accomplishing this be without rewriting any code?
If the application needs the ability to upload then it will always need read/write permissions to the directories it is going to upload to - no amount of rewriting will change this, it's part of the basic functionality. The same applies to editing stylesheets etc.
Reverting changes you make sounds like a very bad security measure - warning you would be fine, but generally you make these changes for a reason and want them to stay.
Hay try this...
Right-click the file and select Properties.
Click on the Security tab.
Click Advanced in the lower right.
In the Advanced Security Settings window that pops up, click on the Owner tab.
Click Edit.
Click Other users or groups.
Click Advanced in the lower left corner.
Click Find Now.
Scroll through the results and double-click on your current user account.
Click OK to all of the remaining windows except the first Properties window.
Select your user account from the list up top and click Edit.
Select your user account from the list up top again and then in the pane below, check Full control under Allow, or as much control as you need.
You’ll get a security warning, click Yes.
On some files that are essential to Windows, you’ll get a “Unable to save permission changes… access is denied” warning and there’s nothing that you can do about it to the best of my knowledge.
Reconsider why you’re using Windows.