I inherited a Plone installation (version 2.5). It was critical that I upgrade it to 3.3.5.
I set up a test environment and got the old version working. I set up 3.3.5 and went through the migration steps. Now whenever I go to a page I get:
Macro Expansion failed
exceptions.KeyError: 'header'
I've looked in the front_page template (I think that's what it's called) and it has that error listed front and center. I tried removing the macro tag and it gives me an error about the macro needing to be within the tabs.
From looking at more documentation it looks like Plone has moved away from using macros. Is there a quick fix to get our site to work as is, or will we have to do some re-writing?
EDITED: From the comments there is a mention of Add-ons needing to be upgraded. How do I know if I have add-ons? How do I know if they need to be upgraded? How do I find out how to upgrade them? The documentation is full of "whats" but very sparse on "Hows".
EDITED: I found the header issue by looking through the old one (there was a header template that was in the old installation but not in the new one, had to figure out how to get it in there), now it's giving me an error about a user-macro="scripts/macros/jsrenderer" and if I remove that there is one for css. These look like standard entries for plone (since the exact same syntax comes up when I google these...but I can't find the location of the macro anywhere. Is this something that has changed in version 3?
EDITED: I think I've got it under control now, jumping back and forth between the two installations. Such a Pain.
Let me know if you need any code. Thanks for your help.
I can only give hints for debugging this error. What you can try is:
Can you find a define-macro="header" in the code? If not, that's what your template tries to look up and fails.
In the ZMI, check the portal_skins -> properties tab. I think most of the views (templates) are mapped as filesystem directory folders. These need to be registered in each skin layer. The order of each entry is important, as that's the way macros are looked up. Check if each layer has access to each directory view.*
Check if a custom product defines yet another 'main_template.pt' which (re-)defines different macros.
From my experience, a lot of customization happened in page templates. In the traceback you should find, which template the error is happening. Try to look up use-macro="" statements which perhaps point to macros which are different or don't exist anymore.
Furthermore, no - page templates with macros are still in use. Good luck!
Related
I was given a Drupal project and asked to figure out how its code base structured and how the project is structured overall.
I successfully installed it using xampp.
Now I see nothing custom in the project:
For blocks I have only Bartik and Rubik. For content type only Basic page. For file types Audio, Document, Image and Video. For menus Main Menu, Management, Navigation and User menu.
So, does it mean that I was given a blank empty project? What else may I check that may have been customly changed in an empty project? What may I have missed while installing the project that may cause it to become empty, without any customisations? Maybe it is possible to check for something in the files of the project?
I am asking a few questions here, since I am not sure which one of them will convey the matter which concerns me. But basically all of them mean the same: I just want to see what someone else did in the project. And the more customisations I will find, the better it will be.
Thank you.
This does look like a virgin install typically does. If you were expecting to see more, perhaps you need to import a database...
Confirm you've imported the project database and that your settings file is pointing to it. It looks like you're using Drupal 8, so the file should be in sites/default/settings.php
Check under Content to see if any nodes have been created. If you have some sort of botched import, you can also try accessing a few nodes randomly at example.com/node/1, example.com/node/2 to check directly in case something is wrong with the index
Other than Nodes, Drupal content can be also in the form of Views. These are available at example.com/admin/structure/views. This is usually for heavily customised content. There are roughly 15 default Views that come with Drupal 8.
A default install will have no Modules installed in /modules. If you're seeing any directories there, it could be that the site was relying on these to display the content you're being asked to admin.
Trust this puts you on the right path. :)
My dilemma: My small team has been pegged with the task of refactoring/redesigning a rather large Drupal site. The site is littered with unused modules and content types, CSS/JS/HTML/etc hacks, and has a myriad of strange work-arounds for external data imports. I am currently the sole backend developer for the team, and our Drupal expertise is beginner level. We cannot build a custom CMS because of the amount of content that the site has combined with the complexity of Drupal's DB structure, it would be impossible to export it reliably; as well, content is being constantly added and modified on a daily basis.
My question: Is there any best practices, tips, advice, or any suggestions that anyone can provide that might aide us in our attempt to refactor this site?
Specifically...
Detecting, disabling, uninstalling, and removing unused modules and QAing afterwards.
Updating modules and QAing (systematic approach?).
Detecting and deleting unused content types.
Detecting and removing unused PHP code (tpls mostly).
Detecting and removing unused CSS/JS.
On modules back-end page you have dependencies shown for every module. Is some other module using it and what other modules current module uses. So, if you see that module is not used by any other module and that it's feature is not needed you can try disabling it first, check if everything works well and finally remove the module.
About content types - go to content, check is there some node of specific content type you doubt it's not needed. If there are nodes of that type try viewing them. It they are not styled well...might be that they are not used/needed.
Php - hmm...you can i.e. add some line of your code writing out some thing, or even saving some text to the file and then open page...see if you'll get some output or something saved into your file. You can even call exit() function and check will it break the site.
Similar with JS - alert something or write to console to see will it be called.
And most important thing - make a backup of all files and database first!
After migrating from 3.3.5 to 4.1, some folders show their contents properly while some give this error
AttributeError: getLocallyAllowedTypes
How can I fix it?
faber
You really need to include more detail when asking others for help. When asking for help with software, it's very important to include not only tracebacks but also what add-ons you are using. Your original question should have mentioned that you're using contentleadimage. It also should have mentioned that you're using Collage, something I only found out from the traceback.
At any rate the problem appears to be that Collage, contentleadimage, or some combination of your add-one are not compatible with 4.1.
I ran into this problem myself when using wsapi4plone.core to sling content across. Some of my ZODBs have been upgraded all the way from 2.0.5 and we decided this migration would be a good opportunity to 'clean' the content.
The fix is to go to the offending folders on the content source, and from the 'Add new' > 'Restrictions' and check the appropriate choice.
MY suspicion is that these were older folders (prior to the property existing) that had not updated properly and had never been edited since. I didn't dig too deep since there were only a few.
Our main web page is Drupal and we would like to use Osticket as our issue tracking system, but there is a problem with Osticket: anybody can create new tickets.
We can protect this by .htaccess, but we don't want do that; we would like to make this protect by Drupal: only authenticated users should access the Osticket page.
Is there a way to achieve this?
Found a solution here:
http://osticket.com/forum/discussion/9910/integrate-with-drupal-7
Here is the relevant part:
Preamble
It just so happens I was doing some off-again on-again work with integrating this into Drupal.
If you're just interested in ensuring a user is logged you're right, you need bootstrap.inc and you're right you end up with useless blank pages.
Solution
I've yet to get to properly documenting, so try this and let me know if I missed something and I'll have another look, however the following should sort the issue:
Duplicate Function Names
osTicket uses db_query() and (I think) db_close() rename the functions to something like db_ost_query() and you'll be fine. (Note I put the 'ost' in the middle to help future find/replace) I can't remember whether all occurrences of the function needed renaming for it to work, but its probably a good idea to do it.
Location of the bootstrap
The bootstrap has all manner of issues if called from outside the root Drupal directory, I gave up finding an answer to this and just kept an file in the root that osticket would include.
Headers, Headers everywhere
Bootstrap seems to like sending additional headers out so you'd want to include your file in an appropriate location (i.e. one of the .inc files). I think this solved everything.
Disclaimer
Of course, remember this will break on any updates and any mods you add you'd have to take this into account. If I've remembered rightly this will get bootstrap up and running and you can run is_user_logged_in() and show or redirect the page.
Further Concerns
I actually had a greater goal in mind in my meddling and so I don't remember whether everything was perfectly cosy after this addition.
I do remember having further issues with headers being sent and when fully bootstrapping the system session usage interfering with ostickets sessions - I think this occurred later though and shouldn't be an issue for you.
An Alternative Solution
When googling, many people suggested simply creating a module and having it iframe the contents inside it, this might be a good enough solution for what you want and would require a whole lot less messing around with ostickets code.
So my problem is exactly the same as this guy's here: http://www.pubbs.net/201003/flex/61462-flexcoders-flash-builder-super-class-regeneration.html , but unfortunately, he got no answer.
After initially generating service classes connecting with PHP, I modified the PHP, added new call specifically.
While the Data/Services window successfully made notice of the changes, including new function in the list, the service super-class didn't change whatsoever. Which baffles me, since all super-classes in generated service and valueObject packages contain an annotation like this:
This is a generated class and is not intended for modification. To customize behavior
of this service wrapper you may modify the generated sub-class of this class - SomethingService.as.
And also the sub-class contains something about "regeneration of the super-class". So obviously, my goal is to force the mentioned regeneration. Any thoughts?
Just had a similar problem and it was driving me nuts. In my case, I am using an Eclipse plug-in for Team Foundation Server (a source control repository). In TFS, files are kept read-only until you check them out. Usually when something behind the scenes tries to modify a file that I have open, the plug-in will check out the file automatically and let it make the changes. For some reason, it didn't in this case.
So for me, all I had to do was check out the file and it would then be able to regenerate (which translates to making the file writable for the rest of you who might have the same issue).
I find that most code generators work once to generate classes, but do not work well updating them. It's really hard (I've worked on them).
Can you correct your classes by hand?