-
Notifications
You must be signed in to change notification settings - Fork 460
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wordpress code blocks (fixes #1186) #1187
Conversation
I guess there are tests :) How should I go about adding some |
Should I make the |
I think the lxml code that is used to write the document is negating my replacement of |
So ignore those replaces and be done with it. As for the rest of the code, it looks good, though it fails the tests and you should fix it. I’d suggest merging it under transform_sourcecode and handling both at the same time (and make sure to end up with a staticmethod) |
Is a staticmethod important? It makes it harder to use a compiled regular expression. I'm personally not a fan of staticmethods. They're too often used when a regular method should be used, just because you didn't happen to need |
Yeah, except I have a lot of these in my own blog I'm importing (a lot of |
Oh, and sorry if I wasn't clear, but I'm not really clear how to test this. Should I write some dummy wordpress blog post and export it? Maybe whoever has the test blog for the current test cases should add them. |
The latter didn't really to a transformation, it just marked the problematic code. Also, don't use a new variable in transform_content, as you might forget to write new_content = func(new_content) instead of new_content = func(content).
staticmethod is used here mostly for organizational reasons. It’s important, because we use the “no self required” thing sometimes.
But what does the output .wp file look like, if you have the replacements on? If it contains regular
I understand. I was misled and thought those replacements are not necessary after all. Sorry if you felt offended there.
You may add stuff to the XML (pay attention to its correctness), or import it to a WordPress blog, make changes and export that out. For the reference, Niko Wenselowski contributed this export in b1661d4 over a year ago — I doubt he still has that blog on WordPress, and even if he did, it’s still easier to modify it manually or with WordPress’ assistance.. |
Things that look like html tags (like |
culprit: https://github.com/asmeurer/nikola/blob/wordpress_code_blocks/nikola/plugins/basic_import.py#L116 we should find a different way to do it, as using lxml with markdown is nuts. |
So I think having |
Oh yeah, that's the bad code. Sorry if that wasn't clear. I should have pointed to that function from the get go. |
Precisely. We need to find a replacement for |
@Kwpolska in fact, it makes a lot of sense because WP imported posts have lots of HTML links in them, and that's acceptable for markdown, and they need replacing to link to the downloaded assets instead. One way to "fix" this would be to temporarily wrap code blocks in Another would be to replace links by using str.replace() but that's rather scary too. |
You may want to take a look at #369 while fiddling with replacer |
I think you're right. As far as I know, the wordpress format is a superset of HTML. I'll probably have to rearrange some of the importer code to fix this. The lxml stuff happens at the very end, just before the content is written. I guess I just need to factor it out into its own method that is overridden in the wordpress importer class. |
This branch didn't apply cleanly, and I can't push here so I took the diff and did #1666, thanks for the fix! |
Thanks! |
This is a basic fix for #1186. If you guys have tests I haven't modified them yet.
All it does is replace
with
(no idea how to render ``` inside of a code block on GitHub) in the Wordpress importer.