I created my own theme (not diazo) the classic way via terminal - I used most of the sunburst parts and redesigned them.
The problem is on my local computer and a vanilla plone 4.16 install everything works fine but on the server the theme uses parts for e.g. the navtree.css (in my theme empty) that seems to be part of the classic plone theme and I really don't know why.
Any ideas?
This means the installation on your local machine differs from the one the server.
I only thing I could imagine with the given informations is, that you have a different theme active.
Go to the ZMI (plone root) -> portal_skins -> Properties (Tab).
Check which theme is active.
I guess in your case on the local machine it's sunburst and on the server it's Plone theme classic.
Please provide more informations if this is not the case.
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".
I'm building a site in drupal 8, and I pushed my code from local to our development box, and on the development box, the Admin Primary Tabs have completely disappeared. Everywhere. The following is a screenshot of the issue.
The code is version controlled (git), and the databases are identical. There are no outstanding configuration changes to synchronize either. I'm pulling my hair out trying to figure out what the issue is. Is there a settings somewhere I'm missing? I've tried logging out, clearing the cache, different browser. Nothing. I wanted to get a second option before submitting an issue report on drupal.org.
#see Where are the primary and secondary tab blocks?
You probably installed the minimal profile. And although these blocks are part of the Seven theme they only get installed in the standard profile. Sounds a like a bug. As they rather should get installed during the installation of the theme instead of during the profile installation.
Try this:
Use Drush or Drupal console or the built-in Configuration
Synchronisation to export your current configuration. Then copy the
config files...
core/profiles/standard/config/install/block.block.seven_local_actions.yml
core/profiles/standard/config/install/block.block.seven_page_title.yml
core/profiles/standard/config/install/block.block.seven_primary_local_tasks.yml
core/profiles/standard/config/install/block.block.seven_secondary_local_tasks.yml
... into your config folder - which is probably
/sites/default/files/config_[hashcode]/sync/. Then do a config import
(using one of those 3 tools above).
I Don't know why the configuration are identical when they shouldn't, but I think that the admin theme does not have the "Primary tabs" blocks in header, you can check your production env Block layout and see if infact the "Primary tabs" block is there (admin/structure/block/list/seven).
Rebuilding the cache on the development server fixed the issue.
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
I installed the latest version of Orchard on my dev machine using a base url of localhost/frankgiotto. Then I moved the site to www.frankgiotto.com and updated my Base URL in the settings.
Site works perfectly. I love everything about it but the one thing is that all the links on every page are mapping to www.frankgiotto.com/frankgiotto/etc and I want simply www.frankgiotto.com/etc
This is driving me insane at the moment.. help anyone!?
p.s.. Yes, I made absolutely sure that Base Url is set to www.frankgiotto.com
Interestingly enough, www.frankgiotto.com/Blog and www.frankgiotto.com/frankgiotto/Blog both work and take me to the same place. Its the same with everything else on the site.
This is little out of context, but to make the orchard urls work without any issue on local just do the following
go to Web project
open property->Web
check for "virtual path", set it empty, and all will be fine
that will make the app run without "/", hence less chance for the above issue
Yes, that is a known issue unfortunately. This is because for now links and image addresses are just stored as plain HTML in the database. Ideally, they would be stored as logical references instead and could be rebased on the production server. This feature does not exist today so what we encourage people to do is to use a port rather than a virtual directory on their dev box if they are going to deploy at the root of a domain. This way relative urls just work. In your case I'm afraid you'll have to manually rebase the existing links and change your dev box configuration.
This is a new one for me. I upgraded a Drupal site from 6.20 to 6.22. After the core upgrade, the block visibility settings are all goofed up. Quite a few that were enabled prior to the upgrade are now disabled. Additionally, the "Page specific visibility settings" are missing for those blocks.
One other clue in this mystery is that, on the main block admin page (/admin/build/block), my three active themes are in a different order. I'm not sure whether that's related, but I've never seen it before.
I do upgrades on a staging server, so my production site is still intact. For now, I'm going to restore the blocks, comparing the prod with staging settings. I'll see if that restores it to fully functional. Regardless, it makes me nervous. I saw no errors or warning during upgrade.
FYI, my general order for doing the upgrade was:
Empty staging site files and dbase.
Take production site offline.
Copy entire prod site to staging.
Dump prod dbase, restore to staging dbase.
Disable all non-core modules. Switch to core theme (Garland).
Upload and expand drupal-6.22.
Move 'sites' directory from old to new.
Run /update.php.
Enable necessary non-core modules.
Run /update.php.
Switch back to custom theme.
Bam, lots of blocks disabled.
This is a bug. See http://drupal.org/node/1173012